SO_SNDBUF/SO_RCVBUF = 256*1024

я сча ляпну глупость: а не втом ли буффере воссоздается порядок пакетов, в случае, если 5ый пришел раньше 2го?

Наверно, чтобы было где держать пакеты (данные) пока их не прочитало приложение.

>я сча ляпну глупость:

мне кажется у тебя получилось :) уровень приложения понятия не имеет (да и не должен) про внутреннюю нумерацию пакетов и то, что происходит реордеринг в случае беспорядка.

> какой тогда смысл выставлять SO_SNDBUF/SO_RCVBUF = 256*1024?

приложение работает не с пакетами, а с потоком данных (tcp). Этот буфер для хранения данных, которые потом будут фрагментироваться и посылаться.

я просто с трудом прадставляю в каком уровне находятся те самые буферы :)

> если 5ый пришел раньше 2го

offtopic.
на сколько вероятна такая ситуация?
я использую udp. Должен ли я вводить для каждой датаграммы seqN,
чтобы потом сортировать их?

ну если путь пакета некороток и лежит через маршрутизатор, то почему бы пакетам и не перемешаться?

если ты задумался о последовательности, то был ли удп правильным выбором?

> если ты задумался о последовательности, то был ли удп правильным выбором

udp - понадобилось из-за multicasting.
всё разрешилось : большой буффер пересылается частями (segments)
фиксированного размера , каждая часть содержит header с номером сегмента, а дальше "дело техники" ... при этом сегменты могут приходить
в любом порядке. 

> Наверно, чтобы было где держать пакеты (данные) пока их не прочитало приложение.

а, почему по-умолчанию не делать его(буффер) максимальным? 

UDP пакеты могут теряться. И приходить не в том порядке. :)

>а, почему по-умолчанию не делать его(буффер) максимальным?

Наверное, память жалко. В том плане, что если приложение перестало читать данные из сокета, то ядро, если не путаю, будет держать до SO_RCVBUF байт данных в памяти, которые там будут висеть пока сокет не закроется (при завершении работы приложения).

В общем точно я ответить не могу, вы просто напишите тестовые программы, допустим запись в сокет в режиме O_NONBLOCK, и посмотреть, сколько получится записать разом (пока не вернется EAGAIN) и сопоставьте это с SO_SNDBUF. И другое приложение, которое откроет udp соект, но не будет из него читать, и записать в этот сокет из другого приложение несколько Мбайт, а потом из первого приложение прочитать сколько получится из сокета и сопоставить это число с SO_RCVBUF.

Пакеты в сети переставляются, обычно это происходит при большой загрузке, не знаю относительно совсем тупых свичей, но даже простой маршрутизирующий свич типа Cisco 3550/3750 уже на это способен. А ещё пакеты с легкостью теряются, про это тоже надо помнить.

понаписал кучу тестов и, в общем, получил, что хотел.
Написал multicast-video ... (on local network)
- поставил  SO_RCVBUF/SO_SNDBUF максимальными
- поигрался с размером udp пакета. Оказалось, что больше ~10k
делать не имеет смысла - максимальная скорость передачи + стабильность
"На глаз", вроде, все пакеты доходят, и в правильном порядке.
Единственное, слишком зафлужена сеть - надо , будет ограничение
на rate добавить.
Неплохая вешч получилась:
- один или несколько компьютеров с несколькими usb-камерами
- один или несколько клиентов, которые все эти камеры видят
на своих экранах.
- Общение либо на прямую с каждым клиентом, либо через private multicast
- управление камерными-серверами через public multicast 
- камер-серверные программы реализованы, как  win-services
- клиент изначально может не знать на каких компах стоят камеры
(общение через public multicast) и сколько их
- задача клиента не только отображать, но и анализировать
видео данные,
например, изображение->в гистограмmу->фитирование и т.д., спасать и пр.

Всё было сделано ~3мес. , начальник считает, что очень долго и медленно,
хотя большинство вещей писались from scratch , с попутным 
самообразованием + переписывались  несколько раз. 
Были проштудированы исходники на предмет multicast-video :
 uftp, vlc, mash  и др.