Socket() жуткие тормоза
 

Имеется инстанция Socket(); которая успешно коннектится на сервер.
Сервер в свою очеред строчит достаточно большими пакетами ~ (65kb)
Так вот на момент приёма пакета, флешплейер подвисает (20% cpu, i7).
После получения пакета всё работает красиво.

Сталкивался кто? может есть какие-нибудь методы буферизации , асинхронизации и прочего, доступного в нормальных полноценных технологиях?

Например?

давай по теме, если конечно знания имеются

Больше чем 1500 байт за раз Вам вряд ли приходит. Предлагаю проверить парсер на предмет торможения (все-таки 64 кб разобрать может быть и долго).

ЗЫ
Насчет полноценности - полноценные люди обычно не придумывают пакеты в 64 кб

http://www.flasher.ru/forum/blog.php?b=173&page=3 тут, в середине, есть мой скрин работы флешевого сокета в Линуксе (оба сокета обмениваются примерно одинаковым количеством информации, но флешевый при этом неимоверно грузит ЦПЮ). Я так понимаю, это нужно принимать как факт / особенность реализации...

Может, десериализация тормозит?

Точнее, больше MTU байт вряд ли.

Нет никакого парсера. Просто сокет, в него просто пишутся данные, никем не обрабатываемые.
Пока сокет данные не соберёт по кусочкам, он сожрёт все доступные ресурсы. Ради хохмы можно передать 1kb по байту, ситуация будет точно такая-же.
В идеале, повесить сборку пакетов на отдельный тред (хаха)
ЗЫ
Судя по твоему представлению, полноценные люди пишут только *****-чатеги из трёх слов.

Да, ситуация схожа. Чтож, ещё одна несостоятельность технологии и криворукость разрабов.

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

А в каком энваронменте тестите? Хочу повторить.

Судя по моему представлению и тому что сказал dimarik, общее количество данных не имеет значения, имеет значение порционность данных (это как раз относится к MTU, ну нет смысла придумывать пакет в 64 кб, все равно ни одна сеть столько за раз не отдаст).
Насчет тредов - попробуй под 11 плеером, были анонсы выноса работы с сетью в отдельный поток.

Да они на моей памяти только и делают что обещают.

Да обычная винда7.
java.net.ServerSocket <-> flash.net.Socket
И там и там строчек кода - кот наплакал.
player какой-то из последних 10.3.xxxxx

Именно так, порционность, её можно регулироват в пределах mtu. Только вот пока (я повторяюсь) флеш свои порции не захавает, сожрёт Все доступные ресурсы.
Насчёт 11 плейера... надо глянуть, как раз релиз скоро.

Добавлено через 7 минут
конечно есть решение: дробить данные на мелкие куски, передавать эти крохи. На стороне флеша, собрав очередной кусочек, отложить его в сторону и попросить у сервера новую порцию... это не тормозит но работает гоораааздо дольше.

Blood, у тя Destiny тормозит из-за сокета. Инфа 100%

Скиньте минимальный код примера (можно залить куда нибудь). Просто мне не воспроизвести. Насчет
Зачем чего-то просить? Просто раздели данные на пакеты по N байт и посылай такими кусками. А уже сам формат пакетов должен показывать, к чему они относятся (к тем 64 кб или уже к каким-то другим).

Релиз уже произошел =)

НЕТ. неверно. это НЕ Работает так как ты себе представляешь.

Я прошу прощения за назойливость, но что "это"? Если мы говорим о TCP-соединении, то именно так оно и работает. То, что не помещается в один пакет, делится на несколько пакетов поменьше, последний из которых получает "приписку" (флаг PSH), которая указывает на конец последовательности.

Все тихо вспоминают ISO OSI и призрачность MTU для вышестоящих уровней.

=) это никоем образом не относится к описываемой проблеме.
Вот если на пальцах.
1) есть N байт (допустим 65кб) которые нам надо переслать
2) на сервере указываем размер отсылаемого буфера в 1000 байт.
3) пишем наш пакет данных в сокет и отправляем. write() && flush(); Понятное дело что сервак начнёт слать пакет порциями по 1000байт.

4) во флешке отрабатывает ProgressEvent, на сокет появляются данные - bytesAvaiable. Причём не факт что там будет 1000байт, там будет точно не больше 1000. Данные эти обязательно нужно считать, иначе сокет засрётся.
5) ProgressEvent отработает ровно такое кол-во раз, сколько нужно для пересылки наших 65кб. В идеале 65kb/1000b раз.
6) Флеш пока не получит по кусочкам все эти 65кб, будет тормозить (забивать CPU процедурой заполнения сокета принимаемыми данными)

Соответственно, если мы пошлём 1кб, то ничего не заметим, всё пройдёт быстро и безболезненно, если 65 - то всё повиснет. Значит надо посылать по 1кб 65 раз =) тобишь 65 раз сделать socket.wirte() и socket.flush(); причём после подтверждения от флеша - мол готов к новой порции.
Это реально работает и не тормозит, но пересылка данных занимает много времени.

Последнее - это лирика на самом деле.

В том же c# или java конечно же такой проблемы нет.

Что-то я не уловил разницу.
Единственное что меняется в работе клиента - это отсылка запросов на новую порцию данных. 65 обращений по 1 байту (условно) вряд ли сильно повлияют на время передачи. В работе сервера вообще ничего не меняется. Так почему же пропадают тормоза?

Ты по прогрессу данные из сокета считываешь или нет?

мда... ладно - проехали.

Да ладно? Правда?

Добавлено через 5 минут
Правда...

да, но отдельного треда для сокета не появилось.