Запись протокола потока: поле размера сообщения или разделитель сообщений?
Моей идеей является поиск с кодами, представляющими финские буквы
new RegExp("\\b"+asciiOnly(searchterm), "gi").test(asciiOnly(title))
. Моя первоначальная идея заключалась в использовании plain encodeURI, но знак%, казалось, мешал регулярное выражение.
Я написал грубую функцию с использованием encodeURI для кодирования каждого символа с кодом более 128, но удаление его% и добавление «QQ» в начале. Это не лучший маркер, но я не мог заставить не буквенно-цифровые работать.
5 ответов
You are using TCP, the packet delivery is reliable. So the connection either drops, timeouts or you will read the whole message. So option #2 is ok.
В зависимости от уровня, на котором вы работаете, №2 может фактически не иметь проблем с выходом из синхронизации (TCP имеет порядковую нумерацию в пакетах и правильно собирает поток закажу вам, если он придет не в порядке).
Таким образом, №2, вероятно, ваш лучший выбор. Кроме того, знание размера сообщения на ранней стадии передачи упростит выделение памяти на принимающей стороне.
Если вы разрабатываете код передачи и приема с нуля, не помешает использовать и заголовки длины, и разделители. Это обеспечит надежность и обнаружение ошибок. Рассмотрим случай, когда вы просто используете №2. Если вы записываете поле длины N в поток TCP, но в конечном итоге отправляете сообщение, размер которого отличается от N, принимающая сторона ничего не узнает и в конечном итоге запутается.
Если вы используете и №2, и №3, хотя и не защищенный от неправильного обращения, получатель может иметь большую степень уверенности в том, что он получил сообщение правильно, если он встречает разделитель после использования N байтов из потока TCP. Вы также можете безопасно использовать разделитель внутри сообщения.
Взгляните на HTTP Chunked Transfer Coding , чтобы увидеть реальный пример использования как # 2, так и # 3.
Я согласен с sigjuice. Если у вас есть поле размера, нет необходимости добавлять и разделитель конца сообщения - однако это хорошая идея. И то, и другое делает вещи более надежными и легкими для отладки.
Рассмотрите возможность использования стандартного формата сетевой строки , который включает как поле размера, так и символ конца строки. Поскольку в нем есть поле размера, можно использовать символ конца строки внутри сообщения.
Есть четвертая альтернатива: протокол с самоописанием, такой как XML.