Дизайн клиента большого объема TCP

Question

У меня есть клиент .NET TCP, который отправляет большие тома сообщений на (TCP-сервер async).

Мне нужно продолжать отправлять сообщения на сервер, но из-за TIME_WAIT у меня закончились порты на клиенте.

Как программа может постоянно и надежно отправлять сообщения без использования всех доступных портов?

Есть ли способ повторного использования одного и того же сокета. Я посмотрел на Disconnect() и флаг сокета REUSEADDRESS, но не нашел хороших примеров их использования. Фактически большинство источников утверждают, что не использовать Disconnect, как для более низкого уровня использования (т. Е. Он только перерабатывает дескриптор сокета).

Я думаю, что мне нужно переключиться на UDP или, возможно, есть метод с использованием C++ и IOCP?

Answer 1

Может ли ваш клиент просто держать один и тот же сокет открытым и отправлять сообщения в цикле?

open socket connection 

while(running) 
    send messages over socket 

close socket connection 

Answer 2

При кодировании как это не работает.

Сервер получает только первое сообщение.

Когда я открываю и закрываю сокет, тогда сервер работает, но у меня заканчиваются клиентские порты.

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

Так как же кодировать сервер Async с помощью .NET. Я следил за примерами MSDN и многочисленными примерами в Интернете.

Answer 3

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

Быстрое открытие Googling оказалось MSDN documentation on building a message queuing service with C#.

Answer 4

Основная идея написания TCP-серверов (на любом языке) состоит в том, чтобы один порт был открыт для прослушивания подключений, а затем создавал новые потоки или процессы для обработки новых запросов на соединение.

open a server socket // this uses the port the clients know about 

while(running) 
    client_socket = server_socket.listen 
    fork(new handler_object(client_socket)) 

Адрес a good example in C#.

Answer 5

Вы можете сохранить сокет открытым, если ваш сервер и клиент знают формат данных. Вы закрываете сокет, чтобы сервер мог «видеть», что клиент «сделан».

Если у вас есть протокол, тогда сервер может «знать», когда он закончил получать блок данных.

Вы можете найти токен конца сообщения somekind, вы можете передать длину сообщения и прочитать остальную часть на основе размера и т. Д. Различные способы сделать это.

Но нет причин постоянно открывать и закрывать соединения с сервером - вот что убивает вас здесь.

Answer 6

TCP пытается очень сильно предотвратить перегрузку в сети.Все новые TCP-соединения начинаются в состоянии «медленного старта», где они отправляют только один пакет и ждут подтверждения с другого конца. Если ACK принят, TCP отправит два пакета, затем четыре и т. Д., Пока не достигнет максимального размера окна.

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

Для этого вам необходимо заставить сервер обрабатывать более одного сообщения в соединении (что означает поиск способа разграничения каждого сообщения). Если ваш сервер поддерживает HTTP-кодирование любого типа, это будет работать; не забудьте проверить какие-либо аргументы или настройки, связанные с «постоянными» соединениями или HTTP 1.1, потому что HTTP передает несколько запросов по одному TCP-соединению.

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