> Теперь о надёжности доставки. > То что промежуточное оборудование изо всех сил стремится > доставить датаграмму, это мы знаем -) > А вот, насколько я понимаю, если датаграмма где-то по > дороге зафрагментируется, и фрагмент потеряется, умрёт же > вся датаграмма? Да, фрагменты доставлены не будут
> Ну и опять же, выбрать малый размер датаграмм тож нехорошо, > общая вероятность потери увеличится. Согласен, но это решается грамотным уведомлением о доставке, раз уж изобретаем TCP :)
> Чудится мне, размер нужно выбирать 1024 байт и не париться. > Ваше мнение? На самом деле для того, чтобы избежать фрагментации пакета необходимо иметь его размер <= MSS
данной сети (mss - Maximum Segment Size). Этот самый MSS равен MTU данной сети - длина заголовка (40b? точнее посмотреть негде - так как пакеты будут оборачиваться заголовками более нижнего уровня). MTU в ethernet = 1500, маршрутизаторы (DLink 604 fe) могут иметь значение 1492, ещё какие-то - ~1400 (1392?), а нижний предел (ppp) - 576 байт (поправьте если не прав). То есть размер данных = 512 байт сто пудов не должен потерпеть фрагментацию. А можно также установить флаг запрета фрагментации пакета, но при этом в сетях с меньшим MTU он не пролезет.
Задача: максимально надёжно доставить сообщение через тырнет на сервер. Причём, размер передаваемого сообщения может превышать то, что возвращает getsockopt с параметром SO_MAX_MSG_SIZE.
Поэтому будет самопальный велосипед навроде TCP ;-), т.е. сообщение может дробиться и отсылаться отдельными датаграммами, а сервером собираться обратно.
Теперь о надёжности доставки.
То что промежуточное оборудование изо всех сил стремится доставить датаграмму, это мы знаем -)
А вот, насколько я понимаю, если датаграмма где-то по дороге зафрагментируется, и фрагмент потеряется, умрёт же вся датаграмма?
Ну и опять же, выбрать малый размер датаграмм тож нехорошо, общая вероятность потери увеличится.
В общем сумбур в голове. Что посоветуете, забить, и выбирать макс. размером то, что скажет getsockopt?
[update]
Примечание: на моей машине getsockopt выдаёт SO_MAX_MSG_SIZE = 65507, т.е. оно не влазит во фрейм езернет и всяко будет много-много раз дробиться по дороге :-(.
Чудится мне, размер нужно выбирать 1024 байт и не париться. Ваше мнение?
Всем заранее спасибо за ответы.
Немного офф. А чем ТСР не устроил?11.03.08 23:00 Автор: ZloyShaman <ZloyShaman> Статус: Elderman
subj, у которых парадигма — нечастый обмен сообщениями, т.е. поточная идеология TCP будет излишней. ИМХО.
Вы представляете на компе несколько десятков тысяч открытых соединений? Многопоточная архитектура обкакается сразу. Есть конечно, асинхронные сокеты и всякие чудные селекты...
Но я думаю, излишне это ;-)
Плюс некоторые сообщения статистического характера, т.е. дошло оно или нет, не так уж и важно, но хорошо, если дошло.
> Теперь о надёжности доставки. > То что промежуточное оборудование изо всех сил стремится > доставить датаграмму, это мы знаем -) > А вот, насколько я понимаю, если датаграмма где-то по > дороге зафрагментируется, и фрагмент потеряется, умрёт же > вся датаграмма? Да, фрагменты доставлены не будут
> Ну и опять же, выбрать малый размер датаграмм тож нехорошо, > общая вероятность потери увеличится. Согласен, но это решается грамотным уведомлением о доставке, раз уж изобретаем TCP :)
> Чудится мне, размер нужно выбирать 1024 байт и не париться. > Ваше мнение? На самом деле для того, чтобы избежать фрагментации пакета необходимо иметь его размер <= MSS
данной сети (mss - Maximum Segment Size). Этот самый MSS равен MTU данной сети - длина заголовка (40b? точнее посмотреть негде - так как пакеты будут оборачиваться заголовками более нижнего уровня). MTU в ethernet = 1500, маршрутизаторы (DLink 604 fe) могут иметь значение 1492, ещё какие-то - ~1400 (1392?), а нижний предел (ppp) - 576 байт (поправьте если не прав). То есть размер данных = 512 байт сто пудов не должен потерпеть фрагментацию. А можно также установить флаг запрета фрагментации пакета, но при этом в сетях с меньшим MTU он не пролезет.
Точно, наверное так и сделаю. Так проще всего.11.03.08 15:03 Автор: HandleX <Александр М.> Статус: The Elderman
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
