Sirik писал(а):Ну вот и пришел к выводу, что все строки будут передаваться в utf-8, не вижу тут проблемы.
Ещё раз: есть проблема в подходе и в идеологии.[*]
Скинхеды имеют бритые головы.
Скинхеды придерживаются националистических взглядов.
Где правильная причинно следственная связь?
- Наличие националистичееский взглядов → наличие бритой головы
- Наличие бритой головы → наличие националистических взглядов
?
У тебя получается второй вариант. Есть ли у тебя такой документ, как
спецификация протокола, который священен и первичен для вас? Я готов поспорить — нет. А должен быть. И если завтра станет совершенно точно ясно: мы не собираем даже близко поддерживать Андроид, зато должны поддерживать Windows Phone, который все строки внутри себя представляет в UCS-2 (
на самом деле я не знаю, в чём он их представляет, и просто делаю предположение), то вы возьмёте и быстренько переделаете протокол так, что все строки до́лжно будет передавать в UCS-2. Это называется «спецификация как дышло».
Sirik писал(а):На счет текста: это простые текстовые посылки, например: 100.100.200.авпынпгаыв и так далее в тоже духе
Что означают и откуда берутся эти данные, особенно текстовая часть? Она может быть произвольной (её вводят пользователи) или набор строчек фиксирован?
Потому что если фиксирован, то нет никакого смысла передавать в юникоде ни числа, ни слова. Вернее, числа в любом случае нет. Единственная разумная причина передавать числа (и возможно — текст) в юникоде — это требование к невероятной гибкости и дальнейшей расширяемости протокола. Но нужна ли такая гибкость?
«100.100.200» занимает 11 байтов. Та же информация могла бы занимать 3 байта. И это было бы даже лучше, с точки зрения экономии трафика. Но на самом деле, экономия трафика — это в 1000 раз менее веская причина так делать, чем кое-что другое.
На самом деле, любые текстовые форматы предполагает необходимость написания сложного парсера. Любой, кто думает, что можно обойтись без сложного парсера — подобен наивному ребёнку. Можно обойтись, конечно, подписавшись создавать отвратительный софт.
Какие проблемы есть с текстом?
- Что делать, если в тексте встретится две точки? (например 100..100.200)
- Что делать, если встретится лишний пробел между числом и точкой? (например 100.100 .200)
- Что делать, если придёт число длиннее, чем мы ожидали? (например 100.000000000000100.200)
- Что делать, если придёт число больше, чем мы ожидали? (например 100.100.9544386846846878/6795435468754445611123)
- Что делать, если придёт число с минусом, а мы ждём только положительные? (например 100.-25.200)
- Что делать, если мы ожидаем и отрицательные тоже, но число пришло с двумя минусами? (например 100.--25.200)
- Что делать, если число префиксировано плюсом: это допустимо или ошибка протокола? (например 100.+100.200)
- Что делать, если посреди числа встретился пробел? (например 100.10 0.200)
- Что делать, если придёт число с минусом, а мы ждём только положительные? (например 100.-25.200)
- Что делать, если придёт число с буквой в середине? (например 100.10a0.200)
- Что делать, если придёт число с буквой в в конце: (это ошибка или просто отбросить букву)? (например 100.100m.200)
- Что делать, если придёт число в «научном формате записи»? (например 100.10e+0.200) При использовании самого глупого подхода в стиле «Split + каскад if-ов + встроенные функции типа Int» такое число будет схавано сервером.
И можно ещё продолжить этот список.
Вот просто три числа, а кол-во нештатных ситуаций перевалило за десяток. Чем более сложным будет протокол, тем больше будет число всяких ситуаций, безальтернативно нуждающихся в особой обработке силами сервера. И самое главное: прежде всего в спецификации нужно будет предусмотреть и описать правила обработки каждой из таких ситуаций. И ещё другой момент: нужно придерживаться каких-то политик по отношению к клиентам, которые шлют нарушенные датаграммы. Потому что если с TCP дело обстоит проще: клиент прислал фигню — отключили его нафиг, то с UDP возможности разорвать соединения нет (как нет и соединения), поэтому нужно придумывать какие-то варианта в зависимости от того, stateless-протокол у тебя или нет. Если не stateless, то конечный автомат для обработки всей этой логики будет просто дико сложным.
Sirik » 21.03.2014 (Пт) 15:09 