Как системный стек TCP / IP различает несколько программ, подключающихся к одному и тому же адресу и порту?
Мы четко рассматриваем этот вопрос в FAQ Rcpp (который входит в качестве виньетки в пакете, находится на сайте CRAN и его зеркалах и на моем сайте).
Короче говоря, Rcpp поддерживает точно такую же инструментальную цепочку, которую поддерживает R. И в Windows, которая является MinGW (порт gcc для Windows), предоставляемой пакетом Rtools для R.
R Core поддерживает только MinGW, и мы делаем то же самое. Если бы можно было скомпилировать R с помощью Visual Studio, все было бы проще, но поскольку Rcpp сидит поверх R, мы играем рукой, с которой мы имеем дело.
Так жаль, ответ - «Нет» Visual Studio.
5 ответов
Две программы фактически не обращаются к «одному и тому же порту». Для TCP соединение определяется кортежем (src_ip, src_port, dst_ip, dst_port).
Исходный порт обычно эфемерный, что означает, что он назначается ОС случайным образом. Другими словами:
Программа A будет иметь:
(my_ip, 10000, your_ip, 80)
Программа B будет иметь:
(my_ip, 10001, your_ip, 80)
Таким образом, ОС может видеть, что это разные «соединения», и может направлять пакеты к нужным объектам сокета.
номер порта источника будет другим, даже если номер порта назначения такой же. ядро свяжет номер порта источника с процессом.
Ответ Кристофера частично правильный.
Программы A и B на самом деле имеют дескриптор для дескриптора сокета, хранящийся в реализации сокета базовой ОС. Пакеты доставляются в этот базовый сокет, и затем любой процесс, имеющий дескриптор этого ресурса сокета, может читать или записывать его.
Например, скажем, вы пишете простой сервер на Unix-подобной ОС, такой как Linux или Mac OSX. .
Ваш сервер принимает соединение, после чего соединение, состоящее из
( src IP, src Port, dest IP, dest Port )
, устанавливается на нижележащем уровне сокетов ОС. Затем вы разветвляете процесс для обработки соединения - теперь у вас есть два процесса с дескрипторами сокета, оба из которых могут читать / записывать его.
Обычно (всегда) исходный сервер закрывает свой дескриптор сокета и пусть это сделает разветвленный процесс.
Когда клиент открывает соединение с целевым портом 80, он использует произвольный неиспользуемый исходный порт на локальном компьютере, скажем, 17824. Интернет затем сервер отвечает этому клиенту, отправляя пакеты на порт назначения 17824.
Второй клиент будет использовать второй неиспользуемый номер порта, скажем, 17825, и поэтому пакеты двух сокетов не будут смешиваться, поскольку они будут использовать другой порт номера на клиентском компьютере.