RCLIO писал(а):Как это проще реализовать?
Qwertiy писал(а):Почему тяжелее, и почему тогда везде им пользуются?
iGrok писал(а):При взаимодействии с сервером БД?! Кто и где им для этого пользуется?!
iGrok писал(а):А тяжелее - потому что текстовые протоколы всегда тяжелее бинарных. Разве это не очевидно?
Qwertiy писал(а):Сервер БД и сервер приложений - весьма близкие понятия.
Qwertiy писал(а):А кто мешает передавать бинарные данные по http?
Qwertiy писал(а):А кто мешает передавать бинарные данные по http?
iGrok писал(а):В своей реализации протокола ты передаёшь 20 байт бинарных данных. Через http ты передаёшь те же 20 байт бинарных данных, плюс ещё 100 байт текстовых http-заголовков. Что эффективнее? Что "тяжелее"? Что экономичнее?
FireFenix писал(а):Самое важное, что http протокол без поддержания подключения и синхронизация юзеров будет через одно место
Qwertiy писал(а):Во-первых, посылать запрос на сервер ради 20 байт - уже извращение.
Qwertiy писал(а):Во-вторых, http гарантирует безошибочность, а твой 20-байтовый пакет?
Qwertiy писал(а):Ты хочешь держать открытое соединение в течение всего времени работы программы?
iGrok писал(а):Какое, к чёрту, извращение? Мы точно об одном и том же говорим?
В 20 байт своего протокола можно уложить запрос на получение/обновление данных по какому-то условию. И вообще много чего можно уложить.
iGrok писал(а):Чего?! HTTP не гарантирует ничего сверх того, что гарантирует TCP.
iGrok писал(а):Зависит от целей. В случае высокой частоты обмена информацией, или необходимости работы в режиме, приближённом к реальному времени, открытие нового соединения на каждый запрос - непозволительная расточительность.
iGrok писал(а):Честно говоря, уже сматернуться хочется. У тебя, вроде бы, всегда адекватные суждения были. А тут вдруг какое-то однобокое восприятие совершенно неконкретизированной задачи. Что случилось?
Qwertiy писал(а):Я думал об ответе сервера в 20 байт, что логично только для подтверждения операций обновления, удаления, но никак не для запроса каких-либо данных.
Qwertiy писал(а):Может опять что-то путаю, но ведь число подключений к серверу ограничено, значит такой вариант ограничит число клиентов, нет?
Qwertiy писал(а):К тому же, размер базы в 50М как-то не очень напоминает высоконагруженную систему...
Qwertiy писал(а):Хм.. А чего неадекватного я тут сделал? Я только высказал своё мнение, задал несколько вопросов и перепутал свойства tcp/ip...
iGrok писал(а):Qwertiy писал(а):Я думал об ответе сервера в 20 байт, что логично только для подтверждения операций обновления, удаления, но никак не для запроса каких-либо данных.
Смотря какие данные. Текущее значение нескольких индикаторов, сгенерированный ИД.. Да много чего можно в 20 байт уместить, как ни крути.
iGrok писал(а):А если нужно просто отдавать нескольким сотням тысяч клиентов значения нескольких индикаторов в реальном времени? 50М вполне хватит под хранение и лог изменений, но это уже хайлоад.
iGrok писал(а):Я ж тебе сразу ответил - для большинства подобных задач действительно вполне покатит вебсервис с общением по http, но есть и другие варианты, и в некоторых случаях они гораздо лучше. А поскольку никаких граничных условий ТС не описал, а по размеру БД ни о чём с уверенностью говорить нельзя, на данный момент все варианты равноправны.
а проще как раз http (с чем ты, кстати, тоже согдасен ), тем более, что .NET предоставляет встроенную функциональность создания веб-сервисов и работы с нимиRCLIO писал(а):Как это проще реализовать? В какую сторону копать?
Qwertiy писал(а):Тем не менее, социальные сети с огромным числом пользователей вполне себе работают по http
Qwertiy писал(а):Так что непонятно, чего мы вообще спорим-то?
iGrok писал(а):Я не спорю, что для данной задачи разумным решением будет вебсервис.
Qwertiy писал(а):Тем не менее, социальные сети с огромным числом пользователей вполне себе работают по http
Qwertiy писал(а):Так что непонятно, чего мы вообще спорим-то?
iGrok писал(а): + round-robin
iGrok писал(а):Ты продолжаешь удивлять меня несостоятельностью аргументации.
iGrok писал(а):Но как именно они работают "по http" ты знаешь? Во-первых, это уже упомянутый мною Comet для поддержания постоянных соединений, во-вторых, это десятки (а то и сотни) фронтэндов с резервированием + round-robin и сотни (а то и тысячи) бэкэндов.
HTTP/1.1 200 OK
Server: nginx/1.2.1
Date: Fri, 21 Jun 2013 19:51:24 GMT
Content-Type: text/javascript; charset=UTF-8
Content-Length: 97
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-store
[{"ts":"1281526768","events":[]},{"ts":"1704109778","events":[]},{"ts":"1887201137","events":[]}]
HTTP/1.1 200 OK
Server: nginx/1.2.1
Date: Fri, 21 Jun 2013 19:51:25 GMT
Content-Type: text/javascript; charset=UTF-8
Content-Length: 32
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-store
{"ts":1627499741,"updates":[]}
iGrok писал(а):Да мы, вроде, и не спорим. Ты просто начал зачем-то наезжать на бинарные протоколы, а я объясняю несправедливость и несостоятельность наезда.
Qwertiy писал(а):По поводу удерживания соединения. Открытая страница диалогов vk регулярно посылает два вида запросов (а зачем два-то?), на которые приходит в ответ json из массива, каждый элемент которого содержит timestamp и массив каких-то данных (как правило пустой)
Dmitriy2003 писал(а):лучше написал-бы + балансировка нагрузки
Qwertiy писал(а):По поводу удерживания соединения. Открытая страница диалогов vk регулярно посылает два вида запросов (а зачем два-то?), на которые приходит в ответ json из массива, каждый элемент которого содержит timestamp и массив каких-то данных (как правило пустой):
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 23