информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Где водятся OGRыАтака на InternetСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / networking
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Как выбрать максимальный размер 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
<"чистая" ссылка>
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach