Как лучше реализовывать архитектуру клиент-сервер

← →
bobah © (2006-07-18 10:55) [40]

Тогда там должно быть наверное ; пропущена и end [37].

И чем тогда [37] отличается от моего кода приведенного в [32]?

Извиняюсь, если чего-то не вижу, но я не вижу.

← →
Медведъ (2006-07-18 11:17) [41]

>bobah © (18.07.06 10:55) [40]
ничем не отличается, ступил, сорри

← →
Slym © (2006-07-18 12:08) [42]

Зачем самоделку делаешь Чем TServerSocket не устроил?

← →
bobah © (2006-07-18 13:56) [43]

> Зачем самоделку делаешь Чем TServerSocket не устроил?

Поздно, я уже сделал:). Плюс ко всему мне так понятнее.

← →
bobah © (2006-07-18 13:58) [44]

Я ОЧЕНЬ люблю функции типа WaitForMultipleObject. В них можно event от других потоков получать, а для моих реализаций это очень удобно.

← →
Evgeny V © (2006-07-18 14:03) [45]

Почитал - думается как быстро реагирует пользователь на изменения показаний приборов не критично, опаздание в плюс несколько секунд допустимо ? Если да, рекомендую модель предложенную Сергей М. А именно подумать о возможности использования клиент-серверной CУБД. Сокеты в явном виде в этом случае можно не использовать (не нужны просто).
В итоге имеем СУБД, сервис(ы) получающие данные от приборов и записывающие их в БД с указанием даты и времени измерения, клиентское приложение, которое по таймеру
(можно и по событиям-алертам субд, если субд поддерживает такой механизм, но лучше по таймеру на мой взгляд, почему -это отдельная тема)
получает обновления с БД, причем в том порядке сортировки, который вам наиболее удобен, т.е. проблема
"
> приходящие на сервер, уходили на другие клиенты в том порядке,
>
> в котором они приходят на сервер

" отпадает, клиент сам выбирает данные в нужном ему порядке.

> Evgeny V

При разработке данной системы, я так и предполагал, что все взаимодействия будут осуществлятся через СУБД, без всяких сокетов. При этом я очень много всего пересмотрел, передумал:
вплоть до того что сменил БД с MySQL4 -> MySQL5 -> MSDE2000. Да, у меня есть журнал событий с указанием времени всех изменений, по которму можно обновлять данные в клиентах, причем только необхадимую часть.
Потом я загорелся сокетами, даже уже не помню почему...

В данный момент все эти механизмы в средней части написания: сокеты, БД, опрос приборов через модем и т.д.
Поэтому сейчас возвращаться, так сказать, к началу не хочеться.

Поэтому окончательно я пришел к следующей схеме:
1) клиенты и сервер непосредственно взаимодействуют с базой данных, причем обе стороны могут её модифицировать.
2)Основное назначение сокетов это, так сказать, общение между клиентом и прибором в "реальном времени", причем эти данные не обязательно сохраняются в базе данных.Иниаторм общения может быть как сервер, так и клиент.
Побочное назначение сокетов (раз уж они есть) это передача ивэнтов с сервера на клиенты сигналящие, что пора обновить данные с БД. Причем ивэнты формируются НЕ от клиентов, а от БД.
3)сервер - это не сервер приложений, а сервер опроса приборов.

> опаздание в плюс несколько секунд допустимо?

Не кретично. Тепло, штука инерционная.

Вот как раз и у нас есть датчик темпиратуры. Event - ну можно формировать аварийные например Event на сокетах или еще каким способом, хотя например в IB/FB или оракл есть соотвествующий механизм. Про MSDE2000 сказать не могу - не знаю. Но так как тепло штука инерционная и датчик возможно не пожарный, а просто мониторинг например состояния погоды или климатики в серверной например, то и без events можно обойтись на мой взгляд, а работать на обновление данных чисто по таймеру из БД.
Задача в этом случае (в случае без сокетов) значительно упрощается на мой взгляд. Хотя конечно условия и постановка вашей задачи вам видней
:-)
Cервер опроса приборов - и у нас он примерно так же зовется, программа опроса приборов выполнена в виде сервиса(ов).

Как лучше реализовывать архитектуру клиент-сервер Найти похожие ветки