Данные TCP буферизуются как у отправителя, так и у получателя. Размер приемного буфера сокета получателя определяет, сколько данных может быть отправлено без подтверждения, а размер буфера отправки отправителя определяет, сколько данных может быть отправлено до того, как отправитель заблокирует или получит EAGAIN/EWOULDBLOCK, в зависимости от блокировки/неблокировки. режим блокировки. Вы можете установить размер этих буферов сокета сколь угодно большим, вплоть до 2^32-1 байт, но если вы установите размер буфера приема клиента больше, чем 2^16-1, вы должны сделать это до подключения сокета, чтобы масштабирование окна TCP могло быть выполнено. согласовываться при рукопожатии соединения, так что старшие 16 бит могут вступить в игру. [Буфер приема сервера здесь не имеет значения, но если вы установите его >= 64 КБ, вам нужно установить его в сокете прослушивания, откуда он будет унаследован принятыми сокетами, опять же, чтобы рукопожатие могло согласовать масштабирование окна.]
Однако я полностью согласен с Мартином Джеймсом в том, что это глупое требование. Он тратит впустую поток, стек потоков, сокет, большой буфер отправки сокета, FD и все другие связанные ресурсы на сервере в течение двух часов и, возможно, влияет на другие потоки и, следовательно, на других клиентов. Это также ложно создает у сервера впечатление, что данные за два часа были получены, хотя на самом деле они были переданы только в приемный буфер, что может привести к неизвестным осложнениям в ситуациях восстановления: например, сервер может быть не в состоянии восстановить данные, отправленные так далеко вперед. Вам лучше не подключаться, пока вы не будете готовы начать получать данные, или же читать и буферизовать данные себе на клиенте для последующей обработки.
person
user207421
schedule
17.10.2012
