![]() |
Socket теряет сообщения
Народ есть проблема - socket теряет сообщения от сервака.
Код AS3:
функцией send шлются строки примерно в 70 символов раз в 120 мс. При тыке мышкой шлется дополнительная строка (единожды) тем же оъемом. На сервер все доходит, обрабатывается и уходит ответ, но почему-то не доходит до флешки (как раз тот самый ответ на событие мыши). Вернее, иногда получается, что ответ доходит, а иногда - нет (50 на 50). Если кто-то сталкивался с подобной проблемой, или есть соображения по этому поводу, то было бы интересно узнать Ваше мнение по поводу решения этой проблемы. |
Не знаю, когда у вас вызывается функция readResponse(), но судя по сигнатуре, не в ответ на какое-либо событие. Попробуйте подписаться на событие ProgressEvent.SOCKET_DATA.
|
Цитата:
|
а само событие вызывается или нет? может не во флеше проблема
|
Если в строке есть нуль-байты, то в консоль будет выводиться только до первого такого байта.
А за такие названия переменных я бы руки по самые уши бы отрывал :) |
Цитата:
Цитата:
З.Ы. не надо мне руки отрывать :) пригодятся еще :) |
\n = 13
\x00 = 0 почувствуйте разницу. |
wvxvw, спасибо за подсказку :)
Появилось подозрение, что сообщения не успевают считываться. Т.е. если одновременно приходит 2 сообщения, и они записываются в байтэррэй сокета (в конце каждого стоит нуль-байт "/x00"), то получается, я могу считать первое сообщение, а остальные пропадают? Как думаете, такое возможно? И еще, кто-нибудь может подсказать, как считать из ByteArray данные, оказавшиеся за нуль-байтом? Добавлено через 43 минуты Исхитрился-таки :) Нашел способ считать инфу за нуль-байтом! Код AS3:
Цитата:
Ладно, буду проверять гипотезу о склеивании пришедших сообщений :) |
ну как, в чем дело было?
|
Сокетное соединение не гарантирует того, что ваши сообщения придут именно такими кусками, как вы их отправили.
То есть, если на сервере вы сделали два раза flush(), то это вовсе не значит, что будет именно два события SOCKET_DATA на клиенте. Если передаваемый кусок данных большой, например видео или картинка, то событий будет куча. А если отправить два мелких сообщения подряд они могут прийти на одно событие. Выход такой -- складываем все пришедшие байты по SOCKET_DATA в буфер, потом анализируем на конец и начало сообщения. То есть есть ли там ЦЕЛОЕ сообщение, если есть -- вычитываем его и обновляем буфер. То есть, например, послали три сообщения, а пришли они в два куска. Считываем полтора с сокета, записываем их в буфер, вычитываем первое из буфера и стираем, оставляя там половину. А со следующего события это все склеивается в буфере и вычитывается. И никаких потерь. Возможно, придется написать некий свой протокол передачи данных. Я использовал определенный формат сообщений. Без символов конца, а с символом начала, кажется, и указанием полной длины сообщения, указанием длины ключа, ключом, указанием длины только лишь передаваемой полезной информации и собственно информации. Что-то в этом роде. Извините, если немного не в тему. |
| Часовой пояс GMT +4, время: 04:07. |
Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.