сетевая ОС Linux
а чего тут такого ?
все равно ручками пакет собирать нужно при получении.
все равно ручками пакет собирать нужно при получении.
Это оптимально по твоему? Это создает дополнительную нагрузку на собирающий хост.
почему ?
с жопы собирать должно быть легче
с жопы собирать должно быть легче
> с жопы собирать должно быть легче
С какого хуя?
С какого хуя?
ну скажем по другому: не сложнее 
сувать в стек.
сувать в стек.
2.4.27-rc2
2.6.7-mm7
14:51:36.816054 > 172.16.12.128 > 172.16.12.1: icmp: echo request (frag 13910:0+)
14:51:36.816068 > 172.16.12.128 > 172.16.12.1: (frag 13910:1480+)
14:51:36.816071 > 172.16.12.128 > 172.16.12.1: (frag 13910:2960)
2.6.7-mm7
14:54:20.288655 < 172.16.12.1 > 172.16.12.128: icmp: echo request (frag 36620:0+)
14:54:20.288772 < 172.16.12.1 > 172.16.12.128: (frag 36620:1480+)
14:54:20.288856 < 172.16.12.1 > 172.16.12.128: (frag 36620:2960)
И в стеке они окажутся в обратном порядке.
У меня 2.4.20-28.7 Thu Dec 18 11:31:59 EST 2003 i686 unknown
Стало быть в конце 2.4.x исправили.
это почему ?
просвети темного
просвети темного
пакеты в обратном порядке посылаются AFAIK во всех версиях
это сделано специально, под тем предлогом, что в этом случае
принимающая сторона после первого же куска будет знать полный размер пакета,
и сможет задействовать некоторые оптимизации (типа сразу выделить нужное количество памяти)
это сделано специально, под тем предлогом, что в этом случае
принимающая сторона после первого же куска будет знать полный размер пакета,
и сможет задействовать некоторые оптимизации (типа сразу выделить нужное количество памяти)
Интересная мысль. В какого рода структурах Linux хранит сетевые данные (очереди интерфейсов, буферы сокетов, очереди реассемблинга)? Я спрашиваю потому, что в BSD-derived стеках не стоит проблема выделения памяти под очередь реассемблинга.
Есть более интересный прикол, недавно в рассылке упомянули.
При передаче по TCP, на каждый n-й сегмент ставится флаг PSH,
потому что какой-то супероптимизированный HTTP-клиент под винду (наверное, с IE как-то связяно)
не передаёт данные в юзер-спейс, пока не увидит этот флаг.
Если флаг не ставить периодически, от он будет пытаться весь файл копить в памяти ядра
Ещё более старый прикол: когда ядро отправляет TCP или UDP пакет с флагом DF,
(что бывает часто, так как в Линуксе PMTU-D реализовано и для TCP, и для UDP
то поле ID ставится в ноль (согласно букве RFC, непонятно, можно ли так делать,
но вроде бы можно, так как дефрагментировать такие пакеты не придётся).
Есть исключение - якобы против какого-то бага в виндовом PPP (не помню какой версии) - для connected-сокетов
ID ставится разный, но тупо - начиная с нуля, и дальше каждый раз ++ (внутри соединения
без этого типа этот виндовый PPP только половину пакетов принимал.
Это важная оптимизация, так как правильным образом вычислять ID дорого - нужно ведь,
чтобы врагу трудно было бы его предугадать.
Я наткнулся на это, когда реализовывал протокол WCCPv2 - долго думал, почему циска
не ест мои пакеты, хотя всё чётко по спецификации сделал.
Оказалось, там тоже ID проверяли зачем-то - только в WCCP, так как тот же SNMP нормально работает.
При передаче по TCP, на каждый n-й сегмент ставится флаг PSH,
потому что какой-то супероптимизированный HTTP-клиент под винду (наверное, с IE как-то связяно)
не передаёт данные в юзер-спейс, пока не увидит этот флаг.
Если флаг не ставить периодически, от он будет пытаться весь файл копить в памяти ядра
Ещё более старый прикол: когда ядро отправляет TCP или UDP пакет с флагом DF,
(что бывает часто, так как в Линуксе PMTU-D реализовано и для TCP, и для UDP
то поле ID ставится в ноль (согласно букве RFC, непонятно, можно ли так делать,
но вроде бы можно, так как дефрагментировать такие пакеты не придётся).
Есть исключение - якобы против какого-то бага в виндовом PPP (не помню какой версии) - для connected-сокетов
ID ставится разный, но тупо - начиная с нуля, и дальше каждый раз ++ (внутри соединения
без этого типа этот виндовый PPP только половину пакетов принимал.
Это важная оптимизация, так как правильным образом вычислять ID дорого - нужно ведь,
чтобы врагу трудно было бы его предугадать.
Я наткнулся на это, когда реализовывал протокол WCCPv2 - долго думал, почему циска
не ест мои пакеты, хотя всё чётко по спецификации сделал.
Оказалось, там тоже ID проверяли зачем-то - только в WCCP, так как тот же SNMP нормально работает.
В линуксе кажется нет такой оптимизации, но я этот код очень давно читал.
Тут похоже действительно, в новых версиях вроде бы порядок стал прямым.
Наверное, когда очередной раз этот вопрос возник, никто не смог привести
пример системы, для которой это актуально.
Структура skbuff довольно хитрая, я детали не знаю к сожалению, но гуру хвалятся,
что эффективнее, чем mbuf
Тут похоже действительно, в новых версиях вроде бы порядок стал прямым.
Наверное, когда очередной раз этот вопрос возник, никто не смог привести
пример системы, для которой это актуально.
Структура skbuff довольно хитрая, я детали не знаю к сожалению, но гуру хвалятся,
что эффективнее, чем mbuf
При передаче по TCP, на каждый n-й сегмент ставится флаг PSH,AFAIK, без PSH стек может передавать данные в сокет, а с PSH должен.
потому что какой-то супероптимизированный HTTP-клиент под винду (наверное, с IE как-то связяно)
не передаёт данные в юзер-спейс, пока не увидит этот флаг.
Если флаг не ставить периодически, от он будет пытаться весь файл копить в памяти ядра
совершенно точно
когда http-сервер отдаёт большой файл, PSH ставить вообще говоря не зачем, кроме как в конце
когда http-сервер отдаёт большой файл, PSH ставить вообще говоря не зачем, кроме как в конце
> Структура skbuff довольно хитрая, я детали не знаю к сожалению, но гуру хвалятся, что эффективнее, чем mbuf
Ну в этом конечно никто не сомневается. Как и раньше не сомневались в том, что фрагменты в обратном порядке эффективнее.
Этих skbuff я так понимаю пул, и реассемблинг упорядочивает цепочку фрагментов вместе с вырванивнием, чтобы удалить пересечения. Тогда проблемы выделения памяти надумана. Или не так?
Ну в этом конечно никто не сомневается. Как и раньше не сомневались в том, что фрагменты в обратном порядке эффективнее.
Этих skbuff я так понимаю пул, и реассемблинг упорядочивает цепочку фрагментов вместе с вырванивнием, чтобы удалить пересечения. Тогда проблемы выделения памяти надумана. Или не так?
Я думаю в современных M$продуктах это уже не актуально.
> Как и раньше не сомневались в том, что фрагменты в обратном порядке эффективнее.
Так не говорили, говорили, что пофиг на порядок, но в обратном порядке
кто-нибудь может захотеть применить вышеописанную оптимизацию.
> Тогда проблемы выделения памяти надумана.
Скорее всего да, к линуксу по крайней мере не относится.
Так не говорили, говорили, что пофиг на порядок, но в обратном порядке
кто-нибудь может захотеть применить вышеописанную оптимизацию.
> Тогда проблемы выделения памяти надумана.
Скорее всего да, к линуксу по крайней мере не относится.
win98 - довольно современный продукт, по крайней мере пользователей огого
секонд эдишн
Оставить комментарий
sergey_m
Наверное, я уже заебал. Но не могу не порадовать вас новыми открытиями в области одной из самых популярных т.н. сетевых ОС.Когда Linux 2.4.x (кто может проверить на 2.6.x?!) высылает ICMP или UDP датаграмму превышающую MTU, то он конечно же её фрагментирует. Интересным является то, что фрагменты высылаются в обратном порядке: