*tcp

а что случается, когда ACK ещё не пришёл, а в буфере уже лежит данных больше чем влезает в MTU? Вроде было бы логичнее данные отправить, но из rfc896 этого не следует.

#tohsti

add comment

прочитал rfc896. теперь я могу смело сказать что знаю что делает TCP_NODELAY. вообще очень годно John Nagle описал чего и как. википидоры так не умеют

#totgni

17 comments

Псач, есть один HTTP-ответ, длины которого я заранее не знаю, поэтому Content-Length я не выставляю, а Chunk Encoding писать западло. Так вот, насколько корректно просто послать FIN в конце передаваемых данных?

#onnthi

2 comments

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

#onztff

8 comments

чат, покритикуй концепцию реализации сервера. существующая реализация не
нравится тем, что блокирующие recv и send происходят в worker thread'ах, что не
есть самое рациональное их использование, ибо числом worker thread'ов хочется
регулировать процессорнозатратные операции, а не ожидание input'а.
итак.

треды ... more →

#oeinze

7 comments

все знают, что recv нужно делать в цикле до тех пор пока не вернёт ноль, -1 или не будет прочитан весь ожидаемый блок данных. так вот. хоть один из вас, профессионалов, проверяет в этом цикле то что у вас началась остановка демона?

#oeiofn

13 comments

пацаны, я всё понял! ничему вообще верить нельзя! если recv на блокирующем сокете вернул нуль, то это вовсе не значит, что удалённый сервак закрыл соединение. на самом деле запросто мог придти сигнал, до того как успели что-то прочесть. кругом подстава.

#osngte

add comment