Может ли MIDAS сервер

← →
sergey32 (2002-07-23 14:50) [0]

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

← →
Polevi (2002-07-23 16:48) [1]

нет - нужно переписывать SConnect

← →
sergey32 (2002-07-23 17:50) [2]

т.е. при работе с APP сервером я не могу получить обратных нотификаций?

← →
Digitman (2002-07-23 18:02) [3]

Можешь. Но - при использовании транспортного уровня, в котором реализована такая возможность. В Borland Socket Server же и в TSocketConnection такая возможность попросту не реализована.

← →
sergey32 (2002-07-23 18:13) [4]

Ок, а есть где-нибудь sources Borland Socket Server ?

← →
Digitman (2002-07-23 18:15) [5]

демо-проект в штатной поставке Делфи : scktsrvr.dpr

← →
sergey32 (2002-07-23 18:29) [6]

т.е. что бы организовать пересылку сообщений пользователю, что таблица была изменена, надо писать свои компоненты?

← →
Digitman (2002-07-23 18:33) [7]

можно свои.
можно доработать существующие.

Могу сказать, что я выбрал 2-й вариант, когда такая необходимость возникла. Хотя это и не первопричина доработки была .. Осн.задача ставилась такова - исключить необходимость регистрации класса фабрики AppServer"а в реестре

← →
sergey32 (2002-07-23 18:37) [8]

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

← →
Polevi (2002-07-23 23:31) [9]

менять надо только SConnect.pas
у меня реализовано так:
в SocketConnection добавлено свойство CLientCallback - сразу после коннекта SC передает его App Server"у
Серверный модуль реализует некий интерфейс IAppServerModule, с помощью которого APp Server передает ему полученный от клиента CLientCallback

примерно 20 строк в SConnect все удовольствие

← →
Polevi (2002-07-23 23:34) [10]

PS
Под AppServer я подразумеваю BSS

← →
Digitman (2002-07-24 08:29) [11]

>Polevi

Ну, про 20 строчек ты загнул, конечно)...

Вся беда в том, что ни BSS ни TSocketConnection не позволяют реализовать асинхронный и независимый маршаллинг прямых и обратных вызовов. Только последовательно - запрос и следом ожидаемый ответ. Если, к примеру, маршаллер клиента транслировал серверу некий его интерфейсный вызов (см. CallSig) и ожидает возвращения результата (см. ResultSig), и в это же время маршаллер сервера выполнит асинхронный обратный вызов (т.е. тоже - CallSig), то коллизии в тек.реализации связки TSocketConnection + BSS обеспечены 100%-но.

← →
Polevi (2002-07-24 09:22) [12]

2Digitman ©
Для callback вызова ответ не требуется

← →
Digitman (2002-07-24 10:01) [13]

>Polevi

Кто тебе это сказал ? Мало ли где и что требуется или не требуется ! Это уже - бизнес-логика, а не транспортный уровень и не маршаллинг. Где это регламентировано ? Что мешает серверу попытаться выполнить обратный вызов интерфейсного метода-функции, если таковой предоставлен клиентом ?

← →
Polevi (2002-07-24 10:12) [14]

2Digitman ©

я имел в виду что callback вызовы могут носить нотификационный характер - в ответ клиент может сам вызвать ф-ию сервера, если нужно

Вот какие изменения внесены мной в SConnect - возможно тут больше 20 строк, но не намного

unit SConnect;
...

const

{ Action Signatures }
...
asSetCallbackInterface=$13;
...

TSocketConnection = class(TStreamedConnection)
...
public
CallbackInterface:IDispatch;
...

procedure TSocketConnection.DoConnect;
begin
...
inherited DoConnect;
SendCallbackInterface;
...
end

procedure TSocketConnection.SendCallbackInterface;
var
Data: IDataBlock;
begin
Data := TDataBlock.Create as IDataBlock;
FInterpreter.WriteVariant(CallbackInterface, Data);
Data.Signature := CallSig or asSetCallbackInterface;
Data := FInterpreter.FSendDataBlock.Send(Data, False);
end;

TDataBlockInterpreter = class
...
public
FCallbackObject:IClientCallbackDisp;
FAppServerModule:IAppServerModule;
...

procedure TDataBlockInterpreter.DoCreateObject(const Data: IDataBlock);
var
V: OleVariant;
VarFlags: TVarFlags;
I: Integer;
begin
V := CreateObject(ReadVariant(VarFlags, Data));
FAppServerModule:=IUnknown(V) as IAppServerModule;
...
end

procedure TDataBlockInterpreter.InterpretData(const Data: IDataBlock);
begin
...
asSetCallbackInterface: DoSetCallbackInterface(Data);
...
end

procedure TDataBlockInterpreter.DoSetCallbackInterface(
const Data: IDataBlock);
var
TmpFlags: TVarFlags;
begin
FCallbackObject:=IClientCallbackDisp(IDispatch(ReadVariant(TmpFlags,Data)));
FAppServerModule.SetClientCallback(FCallbackObject);
end;

← →
sergey32 (2002-07-24 10:26) [15]

В той реализации, на которой написан этот сервер SConnect.pas не используется.
Там используется scctsrvr как основа.
и вторая часть сервера сделана на основе server5_TLB.pas

← →
Digitman (2002-07-24 10:33) [16]

>Polevi

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

но вот ведь "задачка" : чтобы эта "кухня" заработала, придется регистрировать на кл.стороне фабрику класса, реализующего интерфейс IAppServerModule. Как тебе это смотрится ?

← →
sergey32 (2002-07-24 10:49) [17]

← →
Polevi (2002-07-24 10:58) [18]

IAppServerModule содержит лишь один метод SetClientCallback(IUnknown) - этот интерфейс нужен лишь для того чтобы AppServer мог передать модулю клиентский интерфейс, полученный им от клиента. Клиент должен реализовать IClientCallback - не вижу в этом никаких проблем, просто internal auto server..

← →
sergey32 (2002-07-24 11:00) [19]

Задача такая:
есть таблица, в которую записываютя ID_MESSAGEи ID_USER
надо, чтобы при добавлении записи в эту таблицу,
у пользователя, для которого было отправлено сообщение,
на экране появилась мессага, что пришло сообщение.

← →
Digitman (2002-07-24 11:08) [20]

>sergey32

Ты ошибаешься.
Сервер BSS (в проекте scktsrvr.dpr , если ты, конечно, о нем говоришь как об основе) в создаваемых им клиентских транспортных кодовых потоках использует как минимум тот же маршаллер, что и у клиентов BSS (TSocketConnection), именно - класс TDataBlockInterpreter. А этот класс описан и реализован как раз в SConnect.pas

server5_TLB.pas здесь ни при чем - это как раз реализация собственно фабрики класса AppServer"а, это просто бизнес-логика. Мы же здесь говорим о транспорте и маршаллинге как об "узких" местах в стандартном ПО для реализации твоей задачи

← →
sergey32 (2002-07-24 11:20) [21]

т.е. если я допишу в sconnect.pas эти изменения, то я смогу отправлять пользователям сообщения?

← →
Polevi (2002-07-24 11:34) [22]

ты сможешь это сделать если поймешь смысл этих изменений

← →
Digitman (2002-07-24 11:35) [23]

>sergey32

В принципе - да. Но при условии обеспечения четкой сериализации прямых и обратных вызовов. Иначе - "зависания" и клиента и BSS гарантированы.

← →
Digitman (2002-07-24 11:39) [24]

>sergey32

В принципе - да. Но при условии обеспечения четкой сериализации прямых и обратных вызовов. Иначе - "зависания" и клиента и BSS тебе гарантированы. Не предусматривает их транспортный уровень такой возможности. А доработка трансп.уровня - это уж, извини, далеко не 20 строк ...

Иными словами - без доработки транспорта не удастся добиться полной асинхронности и независимости друг от друга прямых и обратных вызовов

← →
sergey32 (2002-07-24 11:52) [25]

Так все-таки можно это сделать или нет?

← →
Digitman (2002-07-24 11:55) [26]

>sergey32

Конечно, можно) Отчего ж нельзя ? Было б желание ...

Может ли MIDAS сервер Найти похожие ветки