Сетевое приложение

[RCLIO]

Здравствуйте!

Пишу небольшое приложение со своей базой данных. Проблем в принципе никаких
Но появилась идея - хранить БД на удалённом сервере. Чтобы, запустив приложение с любого ПК, база всегда была доступна.

Как это проще реализовать? В какую сторону копать?

---------------------------
P.S. База данных у меня - файлик со своей структурой, размером около 50 Мб.

Спасибо.

[Qwertiy]

Использовать нормальную БД - не вариант?

[FireFenix]

Как это проще реализовать?

Клиент-серверное приложение со своим протоколом поверх TCP/IP

[Qwertiy]

Почему tcp/ip?

[iGrok]

Почему tcp/ip?

UDP предлагаешь?

[Qwertiy]

Неа, веб-сервис с http, например. Или просто http...

PS: Я знаю что http основан на tcp/ip, тем не менее

[iGrok]

Http будет "тяжелее", чем свой бинарный протокол, хотя и проще в реализации.

[Qwertiy]

Почему тяжелее, и почему тогда везде им пользуются?

[iGrok]

Почему тяжелее, и почему тогда везде им пользуются?

При взаимодействии с сервером БД?! Кто и где им для этого пользуется?!

А тяжелее - потому что текстовые протоколы всегда тяжелее бинарных. Разве это не очевидно?

[Qwertiy]

При взаимодействии с сервером БД?! Кто и где им для этого пользуется?!

Сервер БД и сервер приложений - весьма близкие понятия. Так что можно сказать, что все веб-сервисы

А тяжелее - потому что текстовые протоколы всегда тяжелее бинарных. Разве это не очевидно?

А кто мешает передавать бинарные данные по http?

[iGrok]

Сервер БД и сервер приложений - весьма близкие понятия.

Да вообще одна фигня, практически. MSSQL и IIS, например.

Я не спорю, что для данной задачи разумным решением будет вебсервис. Приложение с ним будет общаться по http, а сам вебсервис уже будет делать всё, что ему вздумается (хоть работать с sqlite, хоть со своим форматом, хоть с полноценной СУБД, типа postgres/mysql/mssql/etc).

Но я в данном случае поясняю предложенный FireFenixом вариант создания своего бинарного протокола для общения со своей же БД на сервере.

А кто мешает передавать бинарные данные по http?

Никто не мешает. При чём тут "мешает"?
В своей реализации протокола ты передаёшь 20 байт бинарных данных. Через http ты передаёшь те же 20 байт бинарных данных, плюс ещё 100 байт текстовых http-заголовков. Что эффективнее? Что "тяжелее"? Что экономичнее?

[FireFenix]

А кто мешает передавать бинарные данные по http?

Самое важное, что http протокол без поддержания подключения и синхронизация юзеров будет через одно место

[Qwertiy]

В своей реализации протокола ты передаёшь 20 байт бинарных данных. Через http ты передаёшь те же 20 байт бинарных данных, плюс ещё 100 байт текстовых http-заголовков. Что эффективнее? Что "тяжелее"? Что экономичнее?

Во-первых, посылать запрос на сервер ради 20 байт - уже извращение. И http-заголовки в основном необязательные.
Во-вторых, http гарантирует безошибочность, а твой 20-байтовый пакет?

Самое важное, что http протокол без поддержания подключения и синхронизация юзеров будет через одно место

В смысле? Ты хочешь держать открытое соединение в течение всего времени работы программы? Что-то весьма сомнительная затея...

[iGrok]

Во-первых, посылать запрос на сервер ради 20 байт - уже извращение.

Какое, к чёрту, извращение? Мы точно об одном и том же говорим?
В 20 байт своего протокола можно уложить запрос на получение/обновление данных по какому-то условию. И вообще много чего можно уложить.

Во-вторых, http гарантирует безошибочность, а твой 20-байтовый пакет?

Чего?! HTTP не гарантирует ничего сверх того, что гарантирует TCP.

Ты хочешь держать открытое соединение в течение всего времени работы программы?

Зависит от целей. В случае высокой частоты обмена информацией, или необходимости работы в режиме, приближённом к реальному времени, открытие нового соединения на каждый запрос - непозволительная расточительность. Для HTTP, кстати, для подобных задач придуман "костыль" под названием Comet.

Честно говоря, уже сматернуться хочется. У тебя, вроде бы, всегда адекватные суждения были. А тут вдруг какое-то однобокое восприятие совершенно неконкретизированной задачи. Что случилось?

[Qwertiy]

Какое, к чёрту, извращение? Мы точно об одном и том же говорим?
В 20 байт своего протокола можно уложить запрос на получение/обновление данных по какому-то условию. И вообще много чего можно уложить.

Похоже, нет... Я думал об ответе сервера в 20 байт, что логично только для подтверждения операций обновления, удаления, но никак не для запроса каких-либо данных. (Я же сказал "посылать запрос на сервер ради 20 байт - уже извращение", т. е. посылать запрос, целью которого является получить некие данные размером 20 байт с сервера, а не выполнить там какую-либо операцию.)
А запрос на получение уложить в 20 байт - вполне естественно. Id/название сущности и id записи.

Чего?! HTTP не гарантирует ничего сверх того, что гарантирует TCP.

Похоже, перепутал...

Зависит от целей. В случае высокой частоты обмена информацией, или необходимости работы в режиме, приближённом к реальному времени, открытие нового соединения на каждый запрос - непозволительная расточительность.

Может опять что-то путаю, но ведь число подключений к серверу ограничено, значит такой вариант ограничит число клиентов, нет?
К тому же, размер базы в 50М как-то не очень напоминает высоконагруженную систему...

Честно говоря, уже сматернуться хочется. У тебя, вроде бы, всегда адекватные суждения были. А тут вдруг какое-то однобокое восприятие совершенно неконкретизированной задачи. Что случилось?

Хм.. А чего неадекватного я тут сделал? Я только высказал своё мнение, задал несколько вопросов и перепутал свойства tcp/ip...

[iGrok]

Я думал об ответе сервера в 20 байт, что логично только для подтверждения операций обновления, удаления, но никак не для запроса каких-либо данных.

Смотря какие данные. Текущее значение нескольких индикаторов, сгенерированный ИД.. Да много чего можно в 20 байт уместить, как ни крути.

Может опять что-то путаю, но ведь число подключений к серверу ограничено, значит такой вариант ограничит число клиентов, нет?

Зависит от множества вещей. Но, скажем, пару тысяч открытых постоянных коннектов средний сервер спокойно выдержит. Дальше всё зависит от масштабов.
А вот пару тысяч long-poll соединений уже выдержит далеко не каждый веб-сервер.

К тому же, размер базы в 50М как-то не очень напоминает высоконагруженную систему...

А если нужно просто отдавать нескольким сотням тысяч клиентов значения нескольких индикаторов в реальном времени? 50М вполне хватит под хранение и лог изменений, но это уже хайлоад.

Хм.. А чего неадекватного я тут сделал? Я только высказал своё мнение, задал несколько вопросов и перепутал свойства tcp/ip...

Зачем-то начал придираться к бинарным протоколам, причём приводя очевидно несостоятельные аргументы.

Я ж тебе сразу ответил - для большинства подобных задач действительно вполне покатит вебсервис с общением по http, но есть и другие варианты, и в некоторых случаях они гораздо лучше. А поскольку никаких граничных условий ТС не описал, а по размеру БД ни о чём с уверенностью говорить нельзя, на данный момент все варианты равноправны.

[Qwertiy]

Я думал об ответе сервера в 20 байт, что логично только для подтверждения операций обновления, удаления, но никак не для запроса каких-либо данных.

Смотря какие данные. Текущее значение нескольких индикаторов, сгенерированный ИД.. Да много чего можно в 20 байт уместить, как ни крути.

Опять же, сгенерированный id скорее всего подразумевает создание новой записи, и эту цель нельзя назвать "ради получения данных".
Я имел в виду именно запрашивать имеющиеся данные размером 20 байт - их почти всегда лучше поместить вместе с остальными, а не запрашивать отдельно.

А если нужно просто отдавать нескольким сотням тысяч клиентов значения нескольких индикаторов в реальном времени? 50М вполне хватит под хранение и лог изменений, но это уже хайлоад.

Обычно отдаваемые данные ещё и сохраняют, так что размер базы будет при этом быстро (в зависимости от числа датчиков) расти.
Хотя да, пришёл в голову вариант типа мессенджера - там сообщений мало, но проверять появление новых нужно постоянно, так что ты прав
Тем не менее, социальные сети с огромным числом пользователей вполне себе работают по http

Я ж тебе сразу ответил - для большинства подобных задач действительно вполне покатит вебсервис с общением по http, но есть и другие варианты, и в некоторых случаях они гораздо лучше. А поскольку никаких граничных условий ТС не описал, а по размеру БД ни о чём с уверенностью говорить нельзя, на данный момент все варианты равноправны.

Его вопрос:

Как это проще реализовать? В какую сторону копать?

а проще как раз http (с чем ты, кстати, тоже согдасен ), тем более, что .NET предоставляет встроенную функциональность создания веб-сервисов и работы с ними
Так что непонятно, чего мы вообще спорим-то?

[Dmitriy2003]

Тем не менее, социальные сети с огромным числом пользователей вполне себе работают по http

К чему бы это ?

Так что непонятно, чего мы вообще спорим-то?

Я не спорю, что для данной задачи разумным решением будет вебсервис.

[iGrok]

Тем не менее, социальные сети с огромным числом пользователей вполне себе работают по http

Ты продолжаешь удивлять меня несостоятельностью аргументации.

Работа по http там находится в основных требованиях к задаче, т.к. "клиентское приложение" соцсети - это веббраузер. А веббраузеры редко поддерживают что-либо иное.

Но как именно они работают "по http" ты знаешь? Во-первых, это уже упомянутый мною Comet для поддержания постоянных соединений, во-вторых, это десятки (а то и сотни) фронтэндов с резервированием + round-robin и сотни (а то и тысячи) бэкэндов.

Так что непонятно, чего мы вообще спорим-то?

Да мы, вроде, и не спорим. Ты просто начал зачем-то наезжать на бинарные протоколы, а я объясняю несправедливость и несостоятельность наезда.

Но "проще" в данном случае всё же требует конкретизации задачи, т.к. "проще" - не значит правильнее, и если вдруг потом окажется, что у этой базы будет 1000000 клиентов, то придётся либо полностью переделывать уже реализованную работу по http, либо строить леса из костылей.

Я понимаю, что вряд ли. Я понимаю, что, к примеру, ты, описывая такую задачу, обратил бы на это внимание. Но я совершенно не знаю ТС, поэтому вижу в стартовом посте исключительно то, что там написано.

[Dmitriy2003]

+ round-robin

лучше написал-бы + балансировка нагрузки (т.к. round robin - всего лишь один из механизмов и к тому-же самый простой)

[Qwertiy]

Ты продолжаешь удивлять меня несостоятельностью аргументации.

Эм.. Я же с тобой согласился

Но как именно они работают "по http" ты знаешь? Во-первых, это уже упомянутый мною Comet для поддержания постоянных соединений, во-вторых, это десятки (а то и сотни) фронтэндов с резервированием + round-robin и сотни (а то и тысячи) бэкэндов.

Про балансировку нагрузки и множество серверов - естественно. Но и данных у них далеко не 50 мегабайт.
По поводу удерживания соединения. Открытая страница диалогов vk регулярно посылает два вида запросов (а зачем два-то?), на которые приходит в ответ json из массива, каждый элемент которого содержит timestamp и массив каких-то данных (как правило пустой):

Код: Выделить всё

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":[]}

Для того чтобы в этом убедиться достаточно запустить фиддлер

Да мы, вроде, и не спорим. Ты просто начал зачем-то наезжать на бинарные протоколы, а я объясняю несправедливость и несостоятельность наезда.

Я же уже сказал, что ошибся про tcp...

[Dmitriy2003]

По поводу удерживания соединения. Открытая страница диалогов vk регулярно посылает два вида запросов (а зачем два-то?), на которые приходит в ответ json из массива, каждый элемент которого содержит timestamp и массив каких-то данных (как правило пустой)

Ну разве не костыль HTTP, тупо жрет траффик Лучше-бы сосредоточились на разработке замены протоколу HTTP.

[iGrok]

лучше написал-бы + балансировка нагрузки

Согласен, так правильнее.

По поводу удерживания соединения. Открытая страница диалогов vk регулярно посылает два вида запросов (а зачем два-то?), на которые приходит в ответ json из массива, каждый элемент которого содержит timestamp и массив каких-то данных (как правило пустой):

Посмотри профиль обработки запросов на im***.vk.com/im***. Ожидание ответа от сервера занимает от 0 (если пришло сообщение) до 25с. После получения ответа сразу же создаётся новый ожидающий запрос. Вот это и есть работающее long-poll соединение. Т.е. эмуляция постоянного коннекта в рамках http.

А второй, скорее всего, к какому-то другому сервису стучится. У меня только один вид запросов.