Socket, склеенные пакеты
 

код для сокета использую из мануала - http://www.adobe.com/livedocs/flash/...xamplesSummary

при коннекте с серваком, последний сразу шлет клиенту 10 одинаковых пакетов.
А вот функция на событие SOCKET_DATA срабатывает только 2 раза - словно приходит 2 пакета.

Вот первый:
Вот второй:
почему так сильно размеры отличаются? такое чувство, что оставшиеся 9 (12*9=108 байт) пакетов пришли как один...

Если сервер отправляет пакеты с некоторой задержкой - все ок. Если вот сразу кучей - вот такие проблемы.

Надо ставить микроскопическую задержку или какой-то разделитель? null например?

А Вы flush на сервере после каждого сообщения вызываете?

В TCP/IP нет понятия пакета - это потоковый протокол. Пришло все как один вероятно из-за включенного алгоритма нейгла. Все что посылается может приходить абсолютно любыми порциями.
Так что отделять пакеты данных дело рук самого программиста.

отделять на сервере при отправке или на клиенте?

Ну смотри. Представим такой пакет:
- Первый байт - id типа передаваемой сущности
- Потом два байта - размер последующих данных пакета
- сами данные

Алгоритм чтения такой.
Если получили три байта или более - читаем заголовок и размер, понимаем сколько байт нужно еще прочитать чтобы полностью составить пакет.
После того как пакет прочитан, передаем его кому-то на обработку и разгребаем следующие пришедшие данные.

спасибо, будем пробовать

Эмм.. А как тогда гарантировать доставку...?

Вообще говоря TCP/IP - это несколько протоколов разного уровня. И как подсказывает Википедия - пакеты там все таки есть.
Другое дело, что как со стороны FP, так, зачастую, и со стороны сервера, мы работаем не с пакетами, а с порциями данных, которые могут состоять из нескольких пакетов

Хоть сервак не мой, но походу нет. :)

Когда вы пишете что-то в сокет - данные не отправляются сразу, они какое-то время висят в буфере.
flush очищает данные накопленные в буфере сокета. То есть, грубо говоря, выталкивает их - бегите, мол, ребята, на том конце провода вас ждут.
Если делать flush самостоятельно (не дожидаясь пока как-то все само отправится), то шансы на склейку сообщений стремительно падают.
Касательно алгоритма Нейгла - так ни разу с ним и не столкнулся, для меня это все еще миф =)

Да, я не правильно выразился. Это стек протоколов) Но суть в том что программист ни о каких пакетах в TCP/IP не ведает, а работает с потоком данных. Доставку гарантирует сам протокол, программисту для этого делать ничего не нужно.
Другое дело UDP - вот здесь отсылаются пакеты. Гарантия и порядок доставки ложится на программиста (в сетевых шутерах потери не критичны, так что предпочтительней UDP юзать для сетевого мочилова. TCP/IP будет упорно доставлять в том числе и устаревшие данные)