Отправка координат через сокет, но сообщения иногда объединяются, как это предотвратить?

Question

У меня есть сервер AIR, получающий сообщения. У меня есть клиентские приложения Flash, которые отправляют сообщения. Сейчас я просто тестирую с одним клиентом. Боюсь, что эта проблема может усугубиться, когда два клиента отправляют координаты ... еще не проверили.

Я отправляю координаты мыши клиента в виде серии сообщений String, например, «100,200», а затем анализирует его на стороне сервера. Когда пользователь перемещает мышь по клиенту, я отправляю большое количество этих сообщений на сервер.

Большую часть времени на сервере, когда я читаю сообщение, я получаю один x, y ... это здорово. Иногда, когда я читаю сообщение, координаты соединяются вместе ...

Так что, если я отправляю (в быстрой последовательности)

"100200"

"123456"

"111222"

Когда сервер прочитает это, я увижу

"100,200123,456111,222"!

Вот код на стороне клиента:

socket.writeUTFBytes( coordString ); //an x,y pair
socket.flush(); //make sure it's sent

Как мне это предотвратить? Это потому, что я отправляю сообщения в быстрой последовательности?

NB Предложения для возможной отправки в другом формате хороши. На данный момент, я просто пытаюсь сделать это простым. Сообщения в основном представляют собой координаты мыши, поскольку пользователь перетаскивает свою мышь на клиенте. Время от времени появляется сообщение о состоянии. Все сообщения действительно короткие ... например. «ЗЕЛЕНЫЙ», «КРАСНЫЙ» и т. Д. Я мог бы также отправить целые числа, и это уменьшит количество отправляемых байтов. Строка "100" составляет 3 байта, но я думаю, что как целое число это может занять 2 байта ... поэтому я сохраняю там байт. На данный момент я не вижу никакой задержки на сервере, когда он получает координаты мыши и что-то перемещает на экране сервера. Я могу перейти к отправке байтов, если это станет проблемой.

Для тех из вас, кто нашел этот вопрос и отправляет более сложные сообщения, возможно, было бы неплохо использовать AMF, JSON, XML.

Answer 1

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

socket.writeUTFBytes( coordString + String.fromCharCode(0) );

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

Answer 2

То, как используются сокеты, это тот эффект, который вам нужен: цепочка сообщений сводит к минимуму накладные расходы на связь. Вам нужно будет «упаковать» каждое сообщение, чтобы их можно было различить. Если у вас более одного типа сообщений и вам нужно поддерживать четкое разделение, вы можете заключить каждое отдельное сообщение в узел XML или использовать, например, нотацию JSON.

Но если вы собираетесь использовать только координаты, достаточно добавить простой разделитель, такой как ;, либо пробел или разрыв строки:

100,200;123,456;111,222; 

100,200 123,456 111,222

100,200
123,456
111,222

На стороне сервера вам придется добавить код, чтобы разделить полученную строку по этому символу и, конечно, обработать каждый отдельный результат. Я бы, наверное, пошел на разрывы строк - они улучшают читабельность при отладке.

Answer 3

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

Если вы можете быть уверены в размере чисел, которые вы собираетесь отправить (все они целые, фиксированного размера, байты«шорты» удваивается?) вы можете просто написать одно целое за другим, не беспокоясь о пропущенных или путанице, так как вы всегда будете читать одинаковую длину байтов из сокета.Существуют также способы однозначно записать целые числа переменной длины в поток без необходимости в разделителях (во Flash обычно используется UI29).

Однако, если вы планируете отправлять другие виды данных - взгляните на формат AMF.Этот формат был специально разработан для поддержки структур данных ECMAScript, и, в отличие от JSON, он достаточно хорошо служит цели (JSON не может представлять отношения многие ко многим, циклические структуры, и он фактически несколько испортил формат строк, помимо этого,это слишком многословно).Даже если язык, который вы выбрали для написания сервера, не имеет библиотеки AMF, его действительно просто написать, но большинство языков промышленного уровня имеют некоторую реализацию AMF, так что это вряд ли должно быть проблемой.