Основной механизм передачи TCP / сетевое программирование - PullRequest
Новая
       15

Основной механизм передачи TCP / сетевое программирование

0 голосов
/ 19 ноября 2010


Я искал, но не смог найти следующее:
Process1 передает данные через сокет TCP.Код, который выполняет передачу, - это (псевдокод) 

//Section 1
write(sock,data,len);//any language.Just write data
//Section 2

Process1 после того, как запись может продолжиться в разделе 2, но это не означает, что данные были переданы.TCP мог бы буферизовать данные для последующей передачи.
Теперь Process2 работает одновременно с Process1.Оба процесса пытаются отправить данные одновременно .Т.е. у обоих будет код, как указано выше.
Вопрос1: Если оба процесса записывают данные в сокет TCP одновременно , как данные будут в конечном итоге передаваться по проводной связи через IP / OS?
a) Все данные Process1, за которыми следуют все данные Process2 (или в обратном порядке), т. Е. Некоторый порядок FIFO?
или
b) Данные из Process1 & Process2 будут мультиплексированы по IP-уровню (или ОС) по проводами будет отправлено «одновременно»?
Вопрос2: Если бы, например, я добавил задержку, я был бы уверен, что данные из 2 процессов были отправлены последовательно по проводам (например, все данные Process1, за которыми следуютвсе данные Process2)?
ОБНОВЛЕНИЕ:
Process1 и Process2 не являются родительскими дочерними элементами.Также они работают на разных сокетах
Спасибо

Ответы [ 4 ]

4 голосов
/ 19 ноября 2010

Хм, вы говорите об одном сокете, совместно используемом двумя процессами (например, родительским и дочерним)? В таком случае данные будут буферизованы в порядке системных вызовов на выходе (write(2) s).

Если, что более вероятно, вы говорите о двух несвязанных сокетах TCP в двух процессах, то нет никакой гарантии, что данные попадут в провод. Причина в том, что сокеты могут быть подключены к удаленным точкам, которые используют данные с разной скоростью. TCP flow control затем гарантирует, что быстрый отправитель не сокрушит медленного получателя.

2 голосов
/ 19 ноября 2010

Ответ 1: порядок не указан, по крайней мере в тех ОС с поддержкой сокетов, которые я видел. Процессы 1 и 2 должны быть разработаны для взаимодействия, например, разделяя блокировку / мьютекс в сокете.

Ответ 2: нет, если вы имеете в виду просто фиксированную задержку. Вместо этого, пусть процесс 1 подает сигнал о начале процесса 2, указывая, что процесс 1 завершил отправку. Используйте каналы, локальные сокеты, сигналы, разделяемую память или все, что ваша операционная система предоставляет в плане межпроцессного взаимодействия. Отправляйте сигнал только после «промывки» сокета (который на самом деле не сбрасывается).

0 голосов
/ 19 ноября 2010
  1. write () является атомарным;Так же отправить () и друзей.Какой бы один из выполненных первым ни передавал все свои данные, а другой блокировал.
  2. Задержка не нужна, см. (1).

РЕДАКТИРОВАТЬ: но если, как я теперь вижу, выговорить о разных сокетах на процесс ваш вопрос кажется бессмысленным.Приложение не может узнать, как TCP использует сеть, и какое это имеет значение?TCP будет передавать в пакетах до MTU каждый в любом порядке, который он сочтет нужным.

0 голосов
/ 19 ноября 2010

TCP-сокет идентифицируется по кортежу, который обычно равен как минимум (IP-адрес источника, порт источника, IP-адрес назначения, порт назначения).Разные сокеты имеют разные идентифицирующие кортежи.

Теперь, если вы используете один и тот же сокет в двух процессах, это зависит от порядка вызовов write (2).Но вы должны принять во внимание, что write (2) может не потреблять все данные, которые вы ему передали, буфер отправки может быть заполнен, вызывая короткую запись (write () с меньшим, чем запрошено, и возвращаячисло байтов, записанных как возвращаемое значение), вызывая функцию write () для блокировки / ожидания до тех пор, пока не будет свободного места в буфере, или заставляя write () возвращать ошибку EAGAIN / EWOULDBLOCK (для неблокирующих сокетов).

...