winsock 2. безопасность потока для одновременной отправки. tcp

Question

Можно ли отправлять несколько потоков в один и тот же сокет? будет ли чередование потоков или будет блок сокета в первом потоке (при условии tcp)? большинство мнений, которые я нашел, похоже, предостерегают от этого для очевидных опасений чередования, но я также нашел несколько комментариев, в которых говорится об обратном. чередуются опасения о переносе из winsock1 и являются ли они обоснованными для winsock2? есть ли способ настроить winsock2-сокет, который позволит избежать локальной синхронизации?

два противоположных мнения ниже ... кто прав?

комментарий 1

«Winsock 2 реализации должны быть полностью поточно. Одновременное чтение/запись в разных потоках удастся, или не с WSAEINPROGRESS, в зависимости от настройки перекрытой флага, когда создается сокет. В любом случае по умолчанию создаются перекрывающиеся сокеты, поэтому вам не нужно беспокоиться об этом. Убедитесь, что вы не используете NT SP6, если ур на SP6a, вы должны быть в порядке! "

source

комментарий 2

«То же DLL не получает доступ к нескольким процессам как внедрения Windows 95. Каждый процесс получает свою собственную копию записываемого сегмента данных для DLL. модель «все процессы доля» была старая модель Win16, которая, к счастью, мертв и похоронен сейчас ;-)»

source

с нетерпением ждем ваших комментариев! jim

~ edit1 ~ , чтобы уточнить, что я подразумеваю под чередованием. thread 1 отправляет сообщение msg «Hello» 2 отправляет msg «world!». Получатель получает: «Милый мир!». это предполагает, что оба сообщения НЕ отправляются в цикле while. Это возможно?

Answer 1

Я бы действительно советовал делать это в любом случае. Функции отправки могут отправлять меньше, чем вы говорите, по различным очень законным причинам, и если другой поток может войти и попытаться также отправить что-то, вы просто испортите свои данные.

Теперь вы можете писать в сокет из нескольких потоков, но вы больше не контролируете то, что попадает на провод, если у вас нет надлежащей блокировки на уровне приложения.

не рассмотреть вопрос о направлении некоторые данные:

WSASend(sock,buf,buflen,&sent,0,0,0: 

параметр sent будет удерживать нет. фактически отправленных байтов - аналогично возвращаемому значению функции send(). Чтобы отправить все данные в buf, вам придется выполнять цикл WSASend, пока все данные не будут отправлены.

Если, скажем, первый WSASend отправляет все, кроме последних 4 байтов, другой поток может пойти и отправить что-то во время обратной связи и попытаться отправить последние 4 байта.

С надлежащей блокировкой для обеспечения того, что этого не может быть, это не проблема с отправкой из нескольких потоков - я бы этого не сделал, просто для чистого ада это будет отладка, когда что-то пойдет не так.

Answer 2

Возможно ли иметь несколько потоков, отправляемых на один и тот же сокет?

Да - хотя, в зависимости от реализации это может быть более или менее видны. Во-первых, я поясню, где я иду от:

1. C#/.NET 3.5
2. System.Net.Sockets.Socket

общая видимость (т.е. требуется управление) многопоточности и возникающие головные боли будут напрямую зависеть от того, как реализуется сокет (синхронно или асинхронно). Если вы идете по синхронному маршруту, у вас есть много работы по ручному управлению подключением, отправкой и получением нескольких потоков. Я настоятельно рекомендую избегать этой реализации. Усилия по правильному и эффективному выполнению синхронных методов в поточной модели просто не стоят сопоставимых усилий для реализации асинхронных методов.

Я реализовал асинхронный Tcp-сервер за меньшее время, чем потребовалось для реализации потоковой синхронной версии. Async намного проще отлаживать - и если вы намерены использовать Tcp (мой любимый выбор), то у вас действительно мало забот в потерянных сообщениях, отсутствующих данных или что-то еще.

будет чередование потоков или будет блок сокета на первом потоке (при условии tcp)?

Мне пришлось исследовать потоки (из wiki), чтобы я был точным в своем понимании того, что вы просите. Для более глубокого понимания перемежения и смешанных сообщений, обратитесь к этим ссылкам на вики:

1. Real Time Messaging Protocol
2. Transmission Control Protocol

В частности, мощность Tcp лучше всего описывается в следующем разделе:

Из-за перегрузки сети, балансировки нагрузки на трафик или другого непредсказуемого поведения сети, IP pac kets может быть утерян, дублирован или доставлен не в порядке. TCP обнаруживает эти проблемы, запрашивает повторную передачу потерянных пакетов , переупорядочивает пакеты не по порядку и даже помогает свести к минимуму перегрузку сети, чтобы уменьшить возникновение других неполадок . После того, как TCP-приемник окончательно собрал идеальную копию данных, которые первоначально переданы, он передает эту дейтаграмму в прикладную программу. Таким образом, TCP абстрагирует сообщение приложения от базовых сетевых данных.

Что это означает, что с чередованием сообщений будут повторно упорядочиваются в свои сообщения как отправленные отправителя. Ожидается, что потоки будут или будут задействованы в разработке механизма клиент/сервер Tcp с производительностью, будь то с помощью методов async или sync.

Чтобы сохранить розетку от блокировки, вы можете установить ее Blocking на false.

Надеюсь, это даст вам хорошую информацию для работы. Черт, я даже немного научился ...