Экспертная система Delphi.int.ru

Сообщество программистов
Общение, помощь, обмен опытом

Здравствуйте, эксперты!

Допустим что мы пишем систему для небольшой оргнизации. Есть серверная часть с БД где вся иноформация хранится и есть клиентский терминал, в котором продавец указывает какой товар он продал, а менеджер - чего и сколько привез, продал. Права пользователей разные и количество одновременных подключений клиентов - до 10; при этом менеджер должен в реальном времени просматривать подключенных клиентов, все продажи клиентов, остатки. Используем TIdTCPServer и TIdTCPClient из Indy 10, допустим написали прикладной протокол.

Вопрос заключается в том, как при получении на срвере сообщения от клиента с запросом о добавлении записи о продаже оповестить об этом всех менеджеров. Как правильнее на сервере хранить контексты подключений клиентов, как найти именно менеджеров для отсылки сообщения и использовать ли при этом таблицу БД с клиентами (или формировать в оперативной памяти список с подключеными клиентами и ссылками на соответствующие контексты)?

Тут же хочу уточнить - как лучше обрабатывать входящие запросы клиентов - добавлять запись в БД и триггером формировать выборку менеджеров которым нужно разослать и запускать функцию на сервере или сам сервер это делает (как реализовать?)?

Вопрос задал: Roman Novikov (статус: Посетитель) Вопрос отправлен: 22 июня 2009, 09:08 Состояние вопроса: открыт, ответов: 0.

Мини-форум вопроса

Вадим К (статус: Академик), 22 июня 2009, 11:44 [#1]: А клиенты в одной подсети? Или в разных. Галочка "подтверждения прочтения" - вселенское зло.

Roman Novikov (статус: Посетитель), 22 июня 2009, 14:32 [#2]: Предполагается, что они работают через интернет. То есть у сервера статический внешний ip и клиент знает ip и порт.

Roman Novikov (статус: Посетитель), 22 июня 2009, 14:34 [#3]: При этом на каждой торговой точке может быть несколько компьютеров, обьединенных в сеть через маршрутизатор с выходном в интернет.

Вадим К (статус: Академик), 22 июня 2009, 14:56 [#4]: Тогда придется работать с сервером (а можно было бы красиво на UDP сделать). идей две. либо соединения держуться постоянно и в случае чего, сервер всем рассылает сообщения. Либо клиенты время от времени делают запросы на сервер. Но раз уже есть соединение, то наверно первый способ стоит использовать. Сервер может присылать номер записи (то есть её ид), и что случилось (обновилась, удалилась). а Клиент делает запрос и выясняет, что уже точно там такое. Галочка "подтверждения прочтения" - вселенское зло.

Roman Novikov (статус: Посетитель), 23 июня 2009, 11:17 [#5]: Как организовать промежуточные действия? - вот в ченм вопрос. Т.е. пришел на сервер запрос о добавлении новой записи... а вот дальше мне нужно подробно по шагам... в какой момент куда что записывается, как ищутся менеджеры (по какому признаку в какой структуре определются они и их "подключения") которым нужно прислать обновление. Нужно ли мне на сервере сделать к примеру TList и при подключении клиента заносить в него запись с id клиента и ссылкой на что-нибудь вроде контекста подключения? - или какие возможны еще хорошие варианты? А для чего сервер отсылает клиенту id записи? Ведь по сути всегда запись должна приходить к клиенту без его подтверждения. А что если сервер

Roman Novikov (статус: Посетитель), 23 июня 2009, 11:21 [#6]: А для чего сервер отсылает клиенту id записи? Ведь по сути всегда запись должна приходить к клиенту без его подтверждения. Тогда наверное серверу лучше посылать саму запись к которой добавлен код операци (добавление записи/обновление/удаление).

Вадим К (статус: Академик), 23 июня 2009, 12:06 [#7]: А зачем хранить где то ещё список клиентов, если они уже есть? У Вас же держиться соединение с каждым клиентом. Дальше, как клиент работает с базой. Напрямую или через сервер (трехзвенка). Отправка id хороша тем, что клиент знает что спросить у сервера. Клиент может решить и не запрашивать данные (например, он уже запрашивал эти данные). "Ведь по сути всегда запись должна приходить к клиенту без его подтверждения" Может быть, но вот отображать сразу - вот за это ручки программистам отрываются сразу. Обрисовываю картину "сижу, редактирую запись. Тут другой менеджер её тоже отредактировал и до моего клиента добежала запись. Мое редактирование закрывается, и заменяется текущим...." это один с возможных вариантов. А может быть и больше. Я бы делал бы всплывающий тултип, либо просто на форме где то пометку "есть новые данные". По поводу "по шагам". Никак не помогу. Потому что для этого мне придётся писать программу полностью, придумывать протокол, и всё, всё, всё... А мне как то не хочеться этого делать (ну как минимум мне за это никто не платит). Галочка "подтверждения прочтения" - вселенское зло.

Roman Novikov (статус: Посетитель), 12 июля 2009, 14:31 [#8]: >>А зачем хранить где то ещё список клиентов, если они уже есть? У Вас же держиться соединение с каждым клиентом. А как отличить соединение с менеджером от соединения с продавцом? Как вообще и где найти/выделить соединения с менеджерами?

Roman Novikov (статус: Посетитель), 12 июля 2009, 14:32 [#9]: >>Дальше, как клиент работает с базой. Напрямую или через сервер (трехзвенка). Клиенты подключаются к серверу и работают с базой через него (трехзвенка).

Roman Novikov (статус: Посетитель), 12 июля 2009, 14:41 [#10]: >>Отправка id хороша тем, что клиент знает что спросить у сервера. Клиент может решить и не запрашивать данные (например, он уже запрашивал эти данные). Согласен. Я думаю сделать так: вначале все записи присылаются клиенты, а затем при добавлении новой записи или изменении существующей клиенту посылается запись с id и кодом операции - клиент знает что делать (в любом случае должен получить запись и обновить её старый вариант у себя или добавить новую)

Roman Novikov (статус: Посетитель), 12 июля 2009, 14:48 [#11]: >>Может быть, но вот отображать сразу - вот за это ручки программистам отрываются сразу. Обрисовываю картину "сижу, редактирую запись. Тут другой менеджер её тоже отредактировал и до моего клиента добежала запись. Мое редактирование закрывается, и заменяется текущим...." Думается такой вариант: На клиенте у меня спислк(TList), в котором объекты с пришедшими данными, для отображения данных в таблице вызывается отдельная функция по необходимости. Когда приходит обновление или новая запись от сервера - я обновляю запись в TList и если при этом клиент не редактирует записи, то перерисовываю таблицу. Если же пользователь что-то редактирует, то обновляется только TList, а перерисовка вызывается только после того как пользователь отредактировал запись, при этом пришедшие данные могут быть поверх изменены тем что он там наредактировал.

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