[VInchensoo]

У вас localhost и данные отправляются процессу сразу после того, как их положили в системный сокет. В Java-коде данные в системный сокет кладутся несколько раз. Вообще это плохо, но пока у вас код не заработает - наоборот, хорошо . 20Кб - это странное желание. В ethernet 100 обычно размер пакета не превышает 1,5 кб. На магистралях могут использоваться и технологии, где максимальный размер пакета - несколько десятков байт, так что все может быть.

Ну у меня нету огромного опыта работы на java(его вообще крайне мало, есть опыт на других Яп, поэтому пишу и параллельно изучаю java), поэтому не знал, что несколько раз.
Про 20 кб- это скорее из области фантастики, аватарку передать или еще что, но, думаю, такие вещи лучше делать специальными компанентами типа URLLoader.

Если вы привели весь код, то вы не можете определить, "все" или "не все" приходит сразу. Все вызовы в java у вас - блокирующие. Если им не хватает данных, они ждут, пока не придет следующий фрагмент.

Опять-таки, сказалось мое незнание матчасти, буду знать. К сожалению, я только догадываюсь, как многие методы работают.

Возможно, это я вас неправильно понял. Я думал, вы несколько раз одно и то же отправляете. И не все сообщения приходят. Если вы одно сообщение вычитать не можете - это другое. Да, кстати, в c++ вы тоже низкоуровеневые данные не увидите при использовании сокетов.

Да, я отправляю данные 1 раз и не могу их нормально вычитать. Событие слушателя прихода данных вызывается ровно 2 раза и не более, у меня уже батхерт от этой проблемы.

Первое вы точно кроме как "вручную" не проверите. Проверка на пустоту - socket.available. Но это скажет только, что "пока еще данных нет."

Да, я придумал как это использовать, без вычитывания данных, читайте ниже.

Попробуйте на каждой операции вычитывать весь socket.available байт в свой буфер. Если у вас не получается вычитать все данные, возможно, flash не отправляет socketData, если из сокета не было чтения (хотя бы одного байта). Свой буфер затем можно копировать целиком (или по частям) в ByteArray, и уже из него читать данные. Алгоритм примерно такой:
1. Считать данные в свой буфер (byte[]).
2. Проверить, достаточно ли данных в буфере для сообщения.
3. Если данных не достаточно, выходим и ждем следующего события
4. Если данных достаточно - копируем данные в ByteArray, оттуда разбираем данные. "Очищаем" буфер, отмечаем в буфере "свободное" место

Сейчас я делал по такому алгоритму:
1. При срабатывании события я считывал первый байт- число данных в буфере, которое должно быть
2. Далее делал проверку на socket.available, равно или нет числу байт, которой должно там лежать. Если равно, то вызываем обработчик пришедшего пакета.

Снова все уперлось в эту магическую цифру: 2 вызова сокетдата.

Я решил проверить ваше предположение, что событие не вызывается, если не было чтение из буфера после прихода данных.

Каждый раз, когда что-то пришло, я вызывал проверку на то, что socket.available != 0 и считывал 1 байт(чтобы факт считывания был).

Те же бараны в итоге- 2 считывания и все, больше события сокетдата не вызывается.

Для начала буфер можно делать "сплошной" и после выборки из него сообщения сдвигать байты. Потом можно
будет сделать кольцевой буфер, он чуть побыстрее будет (но и сложнее в реализации).

Обернуть, в принципе, не проблема, но, т.к. проблема не в том, что отсутствует считывание, а в чем-то ином, сейчас это ничего не даст.

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

Тут 2 подводных камня:
1. Вдруг событие сработает на 2 раза, а 3, не понятно, что будет с таймером.
2. Этот способ идиотский =)

Может есть еще варианты/предположения, из-за чего это может быть? Я уже грешил в сторону ОС, но, думаю, вряд ли это связано, вряд ли проблема в железе или ОС.

Может еще что-то можете предположить?