Программирование сокетов C ++ Максимальный размер буфера сокетов TCP / IP?
Я использую C ++ TCP / IP сокеты. В соответствии с моими требованиями, мой клиент должен подключиться к серверу и прочитать отправленные им сообщения (это действительно что-то новое, не правда ли), но … в моем приложении мне нужно подождать некоторое время (обычно 1-2 часа ), прежде чем я действительно начну читать сообщения (через recv () или read ()), и сервер все еще продолжает отправлять сообщения.
Я хочу знать, есть ли ограничение на емкость буфера, который хранит эти сообщения в случае, если они не читаются, и чья физическая память используется для буферизации этих сообщений? Отправитель или получатель?
Решение
Данные TCP буферизируются как у отправителя, так и у получателя. Размер буфера приема сокета получателя определяет, сколько данных может находиться в полете без подтверждения, а размер буфера отправки отправителя определяет, сколько данных может быть отправлено до того, как отправитель заблокирует или получит EAGAIN / EWOULDBLOCK, в зависимости от блокировки / отсутствия. режим блокировки. Вы можете установить эти буферы сокетов до 2 ^ 32-1 байт, если хотите, но если вы установите клиентский буфер приема выше 2 ^ 16-1, вы должны сделать это перед подключением сокета, чтобы масштабирование окна TCP могло быть согласованным при установлении соединения, так что старшие 16 бит могут вступить в игру. [Приемный буфер сервера здесь не имеет значения, но если вы установите его> = 64k, вам нужно установить его на слушающий сокет, откуда он будет наследоваться принятыми сокетами, опять же, чтобы рукопожатие могло согласовывать масштабирование окна.]
Однако я полностью согласен с Мартином Джеймсом, что это глупое требование. Он тратит впустую поток, стек потоков, сокет, большой буфер отправки сокетов, FD и все другие связанные ресурсы на сервере в течение двух часов и, возможно, влияет на другие потоки и, следовательно, на других клиентов. Это также ложно создает у сервера впечатление, что данные за два часа были получены, когда они действительно были переданы только в буфер приема, что может привести к неизвестным осложнениям в ситуациях восстановления: например, сервер может быть не в состоянии восстановить данные, отправленные так далеко вперед. Вам лучше не подключаться, пока вы не будете готовы начать получать данные, или же будете читать и буферизовать данные для себя на клиенте для последующей обработки.
Другие решения
Других решений пока нет …