Внезапно максимальный размер MTU у jumbo frames — 9000.
Пойду, посмотрю, не японец ли его разрабатывал…
а что случается, когда ACK ещё не пришёл, а в буфере уже лежит данных больше чем влезает в MTU? Вроде было бы логичнее данные отправить, но из rfc896 этого не следует.
прочитал rfc896. теперь я могу смело сказать что знаю что делает TCP_NODELAY. вообще очень годно John Nagle описал чего и как. википидоры так не умеют
via irc
http://pastebin.com/U7fg6Gbm
Скомпилить, запустить, подождать пока оно что-то напечатает, сильно удивиться.
Псач, есть один HTTP-ответ, длины которого я заранее не знаю, поэтому Content-Length я не выставляю, а Chunk Encoding писать западло. Так вот, насколько корректно просто послать FIN в конце передаваемых данных?
как известно, если долго не писать в сокет, то он протухает
дык вот, напомните мне, я правильно помню, что в протухший сокет можно будет
записать некоторое количество данных (до забивания буфера), но нельзя будет
прочесть реплай, который должен прислать сервер.
или же в протухший сокет может даже запись пофейлиться?
Пстач сетевой, а существует ли какой-то способ добиться следующего, не калеча код tcp/ip стека ядра?
1) При получении tcp-пакета с определенным признаком в заголовке (опции там, или установленные зарезервированные биты, или похуй чо) на определенный порт система должна автоматически установить коннект с ... more →
чат, покритикуй концепцию реализации сервера. существующая реализация не
нравится тем, что блокирующие recv и send происходят в worker thread'ах, что не
есть самое рациональное их использование, ибо числом worker thread'ов хочется
регулировать процессорнозатратные операции, а не ожидание input'а.
итак.
треды ... more →
все знают, что recv нужно делать в цикле до тех пор пока не вернёт ноль, -1 или не будет прочитан весь ожидаемый блок данных. так вот. хоть один из вас, профессионалов, проверяет в этом цикле то что у вас началась остановка демона?
пацаны, я всё понял! ничему вообще верить нельзя! если recv на блокирующем сокете вернул нуль, то это вовсе не значит, что удалённый сервак закрыл соединение. на самом деле запросто мог придти сигнал, до того как успели что-то прочесть. кругом подстава.
какую опцию надо выставить у сокета, чтобы от после send требовал ACK от принимающей стороны и ругался, если ACK'а не пришло?
Любопытный пакет нашёл, tcpstat. Захотелось узнать, сколько трафика кушает биткоин-клиент, быстренько загуглил задачу подсчёта трафика по порту, ну и вот результат. Вдобавок, там есть tcpprof, выдающий много полезной информации по части профиля трафика, чего сколько куда. А трафика оказалось от 5 до 20 килобит ... more →
Никто не в курсе, что за беда с зависшими в воздухе tcp сессиями? Которые не отваливаются долгое время, и являются проблемой забивания узкого канала тырнэта? Что-то вроде вируса или червя. Не знаю как загуглить.
add comment
