я тут провожу некоторое изыскание по реализациям протоколов поверх tcp сокетов (не webscoket) с постоянной связью.
мне доводилось реализовывать подобную связь однажды:
— связь: постоянная
— протокол типа запрос-ответ (запрос инициируется клиентом)
— текстовый (xml)
— обоснование использования именно tcp сокетов(а не HTTP, например): так было проще на тот момент реализовать на стороне сервера
1. могли бы вы поделиться своим опытом, с кратким описанием типа как я привел выше?
2. как часто и с какой целью делается не "запрос-ответ", а когда сервер тоже может писать внезапно в клиентский сокет? плюсы/минусы такого подхода?
3. какие есть общепринятые протоколы подобной схемы, которые можно реализовать самостоятельно. На ум приходит HTTP, но хотелось бы что-то еще и попроще, к тому же он не всегда keep-alive
Здравствуйте, Quadri, Вы писали:
Q>- связь: постоянная
Пофиг. Важно наличие NAT и путей его обхода, важно качество сети и производительность клиента. Q>- протокол типа запрос-ответ (запрос инициируется клиентом)
Это везде так. Q>- текстовый (xml)
Лучше json, xml слишком ибыточный в 95% случаев. Q>- обоснование использования именно tcp сокетов(а не HTTP, например): так было проще на тот момент реализовать на стороне сервера
С т.з. сети это одно и тоже. ХТТП даёт только доп. уровень абстракции с плюшками в виде HTTPS.
Q>1. могли бы вы поделиться своим опытом, с кратким описанием типа как я привел выше?
Это мало что даёт для нормального ответа тебе. Q>2. как часто и с какой целью делается не "запрос-ответ", а когда сервер тоже может писать внезапно в клиентский сокет?
Когда на сервере меняются шареные данные в общем смысле и их надо показывать всем клиентам в режиме online. Q>3. какие есть общепринятые протоколы подобной схемы, которые можно реализовать самостоятельно.
ТСП и протокол поверх него, например, на базе protobuf.
В общем, почему сейчас все юзают HTTP и вёбсокеты, причина проста — одна дырка под 80/8080 порт всегда открыта на фаерволе, не надо обходить НАТ в общем случае, есть куча способов аутентификации/шифрования из коробки которая есть любом HTTP сдк, и ещё, поддержка http есть в любых фреймворках, любых языках и платформах вроде уродства Node.js.
Здравствуйте, Quadri, Вы писали:
Q>- обоснование использования именно tcp сокетов(а не HTTP, например): так было проще на тот момент реализовать на стороне сервера
Я бы взял HTTP, и JSON вместо XML.
Q>2. как часто и с какой целью делается не "запрос-ответ", а когда сервер тоже может писать внезапно в клиентский сокет? плюсы/минусы такого подхода?
Когда на сервере может что-то произойти само по себе, а не в ответ на клиентский запрос, и клиенту про это стоило бы знать.
Q>3. какие есть общепринятые протоколы подобной схемы, которые можно реализовать самостоятельно. На ум приходит HTTP, но хотелось бы что-то еще и попроще, к тому же он не всегда keep-alive
HTTP самый удобный, потому что вся сетевая инфраструктура под него уже заточена. Например, под HTTP вряд ли придется ковырять дырку в фаирволе.
Keep-alive он или нет, это вопрос оптимизации, а не семантики. Хотя мне вот попался киосеровский МФУ, которому оказалось не все равно, с кипалайвом к нему приходят, или без. Но это уж его бага, а не фича.
Q>>1. могли бы вы поделиться своим опытом, с кратким описанием типа как я привел выше? K>Это мало что даёт для нормального ответа тебе.
Спасибо.
Все это (json лучше, что такое HTTP и почему используется и прочее прочее) я и так прекрасно знаю.
Мне нужны примеры конкретных случаев, для примера я описал свой опыт.
Если мне нужно будет больше, я создам другую тему или задам уточняющие вопросы, но сейчас мне нужно именно то что я спросил в исходном посте.
Здравствуйте, Quadri, Вы писали:
Q>Мне нужны примеры конкретных случаев, для примера я описал свой опыт.
Я писал всё, в разных видах и под разным соусом под клиент-сервер. Единственное что я вынес из этого — любое написание нового это повторение старого, но с новыми граблями. Единсвтенное что я не делал, это децентрализованные P2P системы. Вот там HTTP особого смысла не имеет.
Здравствуйте, Kernan, Вы писали:
K>Я писал всё, в разных видах и под разным соусом под клиент-сервер.
отлично, так поделитесь соответствующим примером!
K>Единственное что я вынес из этого — любое написание нового это повторение старого, но с новыми граблями.
Абсолютно согласен, но у меня интерес академический.
K>Единсвтенное что я не делал, это децентрализованные P2P системы. Вот там HTTP особого смысла не имеет.
+
Здравствуйте, Kernan, Вы писали:
Q>>- связь: постоянная K>Пофиг. Важно наличие NAT и путей его обхода, важно качество сети и производительность клиента.
Не пофиг. Где-то есть сущности, персистентные между соединениями, где-то нет.
Q>>- протокол типа запрос-ответ (запрос инициируется клиентом) K>Это везде так.
Нет, не везде. Есть симметричные (SIP), есть с асинхронными оповещениями от сервера (IMAP4).
K>В общем, почему сейчас все юзают HTTP и вёбсокеты, причина проста — одна дырка под 80/8080 порт всегда открыта на фаерволе, не надо обходить НАТ в общем случае, есть куча способов аутентификации/шифрования из коробки которая есть любом HTTP сдк, и ещё, поддержка http есть в любых фреймворках, любых языках и платформах вроде уродства Node.js.
Здравствуйте, Quadri, Вы писали:
Q>я тут провожу некоторое изыскание по реализациям протоколов поверх tcp сокетов (не webscoket) с постоянной связью. Q>мне доводилось реализовывать подобную связь однажды: Q>- связь: постоянная Q>- протокол типа запрос-ответ (запрос инициируется клиентом) Q>- текстовый (xml) Q>- обоснование использования именно tcp сокетов(а не HTTP, например): так было проще на тот момент реализовать на стороне сервера
Q>1. могли бы вы поделиться своим опытом, с кратким описанием типа как я привел выше?
Очень много неизвестных пока в этом описании. Цель протокола под NDA, или что-то таки можете описать?
Какого рода взаимодействие? Есть ли в нём долгоживущие сущности двух сторон?
Похоже ли это на RPC?
Может ли сервер проявлять инициативу в конкретных действиях, а не просто отвечать клиенту?
Q>2. как часто и с какой целью делается не "запрос-ответ", а когда сервер тоже может писать внезапно в клиентский сокет? плюсы/минусы такого подхода?
Сколько угодно.
IMAP: сервер присылает оповещения типа "в ящике появилось новое письмо", "соседний клиент удалил 20 писем и поменял флаги на остальных".
SIP, IAX и прочая телефония: ремота решила послать факс, включить шифрование, положить трубку и т.п.
До чёрта разных веб-сервисов: появилось что угодно новое. Чат — новое сообщение. Мониторилка — обновились статусы объектов. Обычно их стараются, да, загонять на websocket, но есть и альтернативы.
Мессенджеры: и снова — новое сообщение.
Минус по сути только один: не ложится в схему "запрос-ответ" и пассивного сервера. Поэтому надо уметь в асинхронность.
Q>3. какие есть общепринятые протоколы подобной схемы, которые можно реализовать самостоятельно. На ум приходит HTTP, но хотелось бы что-то еще и попроще, к тому же он не всегда keep-alive
Ну тот же IMAP для начала. Всю почтовую специфику можно выкинуть из рассмотрения, смотрите на тегирование сообщений в обе стороны.
Здравствуйте, reversecode, Вы писали:
R>вас на гитхабе забанили ?
Гитхаб сейчас не сильно отличается от всего интернета — "искать в нём это как пить из включенного пожарного брандспойта" (c).
Так что без указаний на конкретные названия это, мягко говоря, не ответ.
Здравствуйте, Kernan, Вы писали:
K>В общем, почему сейчас все юзают HTTP и вёбсокеты, причина проста — одна дырка под 80/8080 порт всегда открыта на фаерволе, не надо обходить НАТ в общем случае, есть куча способов аутентификации/шифрования из коробки которая есть любом HTTP сдк, и ещё, поддержка http есть в любых фреймворках, любых языках и платформах вроде уродства Node.js.
И еще куча всякого готового. Прокси, балансировщики и тд и тп.
Здравствуйте, vsb, Вы писали:
vsb>Сейчас надо использовать QUIC. TCP уже устарел.
Я бы поспорил. Во-первых, есть такое мнение, что сетевая инфраструктура просто не готова к тому, что весь трафик из TCP вдруг превратится в UDP. Во-вторых, у QUIC'а, насколько я в курсе, не очень хорошо с практическими реализациями.
это называется сделайте ресерч за меня
ТС можно сказать с нулевыми знаниями в сетевом кодинге набросил и ждет..
я больше чем уверен что дальше этого топика он не уйдет
те кому надо делают молча ресерчи и создают решения
Здравствуйте, netch80, Вы писали:
N>Очень много неизвестных пока в этом описании. Цель протокола под NDA, или что-то таки можете описать? N>Какого рода взаимодействие? Есть ли в нём долгоживущие сущности двух сторон? N>Похоже ли это на RPC? N>Может ли сервер проявлять инициативу в конкретных действиях, а не просто отвечать клиенту?
Никакого конкретного протокола нет и не планируется. Вопрос задан с целью расширить кругозор и посмотреть "а как оно бывает/принято в жизни"
N>Сколько угодно. N>IMAP: сервер присылает оповещения типа "в ящике появилось новое письмо", "соседний клиент удалил 20 писем и поменял флаги на остальных". N>SIP, IAX и прочая телефония: ремота решила послать факс, включить шифрование, положить трубку и т.п. N>До чёрта разных веб-сервисов: появилось что угодно новое. Чат — новое сообщение. Мониторилка — обновились статусы объектов. Обычно их стараются, да, загонять на websocket, но есть и альтернативы. N>Мессенджеры: и снова — новое сообщение.
N>Минус по сути только один: не ложится в схему "запрос-ответ" и пассивного сервера. Поэтому надо уметь в асинхронность.
+
N>Ну тот же IMAP для начала. Всю почтовую специфику можно выкинуть из рассмотрения, смотрите на тегирование сообщений в обе стороны.
Здравствуйте, Pzz, Вы писали:
vsb>>Сейчас надо использовать QUIC. TCP уже устарел.
Pzz>Я бы поспорил. Во-первых, есть такое мнение, что сетевая инфраструктура просто не готова к тому, что весь трафик из TCP вдруг превратится в UDP.
Но это проблемы сетевой инфраструктуры. Причём очень скоро весь интернет начнёт работать через QUIC, поэтому эти проблемы ответственным за инфраструктуру придётся решать так или иначе. Гугловые серверы уже работают, кстати. Гугл это как стихийное бедствие. Можно его не любить, но не считаться с ним нельзя.
Кстати, а о каких именно проблемах речь?
Pzz>Во-вторых, у QUIC'а, насколько я в курсе, не очень хорошо с практическими реализациями.
Pzz>Семантически QUIC более-менее эквиавалентен HTTP/2.
QUIC даёт шифрование, мультиплексирование и автоматическую миграцию при смене адреса. По-моему все три фичи жизненно необходимы в любом сетевом софте.
Здравствуйте, vsb, Вы писали:
vsb>Кстати, а о каких именно проблемах речь?
Ну не рассчитаны все эти дивные сетевые коробочки, из которых свинчен интернет, на то, что по ним пойдет UDP тугим потоком. Пакеты TCP естесвенным образом образуют поток, и все, довольно дорогие, роутинговые решения можно принять один раз, а потом отправлять каждый следующий пакет уже по накатанным рельсам, а в случае UDP каждый пакет роутится отдельно.
Все это, конечно, починят со временем. Но вряд ли крупные провайдеры побегут в магазин за новыми кисками просто потому, что гуглю так приспичило. И киска тоже вряд ли починит эти проблемы тривиальным апгрейдом прошивки, скорее они новые коробочки понавыпускают. А сейчас провайдеры просто поставят UDP-трафику приоритет пониже, чтобы он их инфраструктуру с ума не сводил, и будут жить дальше, как прежде.
Pzz>>Во-вторых, у QUIC'а, насколько я в курсе, не очень хорошо с практическими реализациями.
Pzz>>Семантически QUIC более-менее эквиавалентен HTTP/2.
vsb>QUIC даёт шифрование, мультиплексирование и автоматическую миграцию при смене адреса. По-моему все три фичи жизненно необходимы в любом сетевом софте.
По сравнению с HTTP/2, QUIC дает, в некоторых случаях, более быстрый старт соединения (TLS+TCP требует сначала пары round-trip'ов, чтобы договориться о TCP, а потом примерно столько же, чтобы договориться о шифровании, а QUIC позволяет это совместить, и плюс потом еще round-trip, чтобы договориться о переходе от HTTP/1.1 до HTTP/2). Шифрование и мультиплексирование есть в HTTP/2.
Что для автоматической миграции, я плохо знаю, как она устроена в QUIC, и рассуждать о ней не могу.
У QUIC и HTTP/2 примерно одинаковая семантика, но QUIC в некоторых случаях работает быстрее. Это вопрос эффективности, а не новых возможностей.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, netch80, Вы писали:
N>> смотрите на тегирование сообщений в обе стороны.
S>А можно где почитать или в кратце рассказать о чем речь?
Похоже речь об этом:
The client command begins an operation. Each client command is
prefixed with an identifier (typically a short alphanumeric string,
e.g., A0001, A0002, etc.) called a "tag". A different tag is
generated by the client for each command.
Example: C: A003 CREATE owatagusiam/
S: A003 OK CREATE completed
C: A004 CREATE owatagusiam/blurdybloop
S: A004 OK CREATE completed
