Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
|
Немного офф. А чем ТСР не устроил? 11.03.08 23:00 Число просмотров: 2924
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
|
|
|
|
<networking>
|
Как выбрать максимальный размер UDP датаграммы? [updated] 11.03.08 11:25
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 11.03.08 12:10 Количество правок: 2
|
Задача: максимально надёжно доставить сообщение через тырнет на сервер. Причём, размер передаваемого сообщения может превышать то, что возвращает getsockopt с параметром SO_MAX_MSG_SIZE.
Поэтому будет самопальный велосипед навроде TCP ;-), т.е. сообщение может дробиться и отсылаться отдельными датаграммами, а сервером собираться обратно.
Теперь о надёжности доставки.
То что промежуточное оборудование изо всех сил стремится доставить датаграмму, это мы знаем -)
А вот, насколько я понимаю, если датаграмма где-то по дороге зафрагментируется, и фрагмент потеряется, умрёт же вся датаграмма?
Ну и опять же, выбрать малый размер датаграмм тож нехорошо, общая вероятность потери увеличится.
В общем сумбур в голове. Что посоветуете, забить, и выбирать макс. размером то, что скажет getsockopt?
[update]
Примечание: на моей машине getsockopt выдаёт SO_MAX_MSG_SIZE = 65507, т.е. оно не влазит во фрейм езернет и всяко будет много-много раз дробиться по дороге :-(.
Чудится мне, размер нужно выбирать 1024 байт и не париться. Ваше мнение?
Всем заранее спасибо за ответы.
|
|
Немного офф. А чем ТСР не устроил? 11.03.08 23:00
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
|
|
|
| |
Сервер будет иметь очень много клиентов, 12.03.08 08:42
Автор: HandleX <Александр М.> Статус: The Elderman
|
subj, у которых парадигма — нечастый обмен сообщениями, т.е. поточная идеология TCP будет излишней. ИМХО.
Вы представляете на компе несколько десятков тысяч открытых соединений? Многопоточная архитектура обкакается сразу. Есть конечно, асинхронные сокеты и всякие чудные селекты...
Но я думаю, излишне это ;-)
Плюс некоторые сообщения статистического характера, т.е. дошло оно или нет, не так уж и важно, но хорошо, если дошло.
|
|
512? 11.03.08 12:35
Автор: Ustin <Ustin> Статус: Elderman
Отредактировано 11.03.08 12:35 Количество правок: 1
|
> Теперь о надёжности доставки.
> То что промежуточное оборудование изо всех сил стремится
> доставить датаграмму, это мы знаем -)
> А вот, насколько я понимаю, если датаграмма где-то по
> дороге зафрагментируется, и фрагмент потеряется, умрёт же
> вся датаграмма?
Да, фрагменты доставлены не будут
> Ну и опять же, выбрать малый размер датаграмм тож нехорошо,
> общая вероятность потери увеличится.
Согласен, но это решается грамотным уведомлением о доставке, раз уж изобретаем 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
|
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
