Сообщение Re: tcp сокет - протоколы от 05.12.2019 10:49
Изменено 05.12.2019 10:54 Kernan
Re: tcp сокет - протоколы
Здравствуйте, Quadri, Вы писали:
Q>- связь: постоянная
Пофиг. Важно наличие NAT и путей его обхода, важно качество сети и производительность клиента.
Q>- протокол типа запрос-ответ (запрос инициируется клиентом)
Q>- текстовый (xml)
Лучше json, xml слишком ибыточный в 95% случаев.
Q>- обоснование использования именно tcp сокетов(а не HTTP, например): так было проще на тот момент реализовать на стороне сервера
С т.з. сети это одно и тоже. ХТТП даёт только доп. уровень абстракции с плюшками в виде HTTPS.
Q>1. могли бы вы поделиться своим опытом, с кратким описанием типа как я привел выше?
Это мало что даёт для нормального ответа тебе.
Q>2. как часто и с какой целью делается не "запрос-ответ", а когда сервер тоже может писать внезапно в клиентский сокет?
Когда на сервере меняются шареные данные в общем смысле и их надо показывать всем клиентам.
Q>3. какие есть общепринятые протоколы подобной схемы, которые можно реализовать самостоятельно.
ТСП и протокол поверх него, например, используя protobuf.
В общем, почему сейчас все юзают HTTP и вёбсокеты, причина проста — одна дыка под 80/8080 порт всегда открыта, не надо обходить НАТ в общем случае, есть туча способов аутентификации/шифрования из коробки которая есть любом HTTP сдк.
Q>- связь: постоянная
Пофиг. Важно наличие NAT и путей его обхода, важно качество сети и производительность клиента.
Q>- протокол типа запрос-ответ (запрос инициируется клиентом)
Q>- текстовый (xml)
Лучше json, xml слишком ибыточный в 95% случаев.
Q>- обоснование использования именно tcp сокетов(а не HTTP, например): так было проще на тот момент реализовать на стороне сервера
С т.з. сети это одно и тоже. ХТТП даёт только доп. уровень абстракции с плюшками в виде HTTPS.
Q>1. могли бы вы поделиться своим опытом, с кратким описанием типа как я привел выше?
Это мало что даёт для нормального ответа тебе.
Q>2. как часто и с какой целью делается не "запрос-ответ", а когда сервер тоже может писать внезапно в клиентский сокет?
Когда на сервере меняются шареные данные в общем смысле и их надо показывать всем клиентам.
Q>3. какие есть общепринятые протоколы подобной схемы, которые можно реализовать самостоятельно.
ТСП и протокол поверх него, например, используя protobuf.
В общем, почему сейчас все юзают HTTP и вёбсокеты, причина проста — одна дыка под 80/8080 порт всегда открыта, не надо обходить НАТ в общем случае, есть туча способов аутентификации/шифрования из коробки которая есть любом HTTP сдк.
Re: tcp сокет - протоколы
Здравствуйте, 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.
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.