Алгоритм обмена данными ?

← →
half_litre (2004-05-31 13:16) [0]

Дано :
(СС)Сокет сервер (stThreadBlocking-??) получает от клиента (СК)
строку (набор параметров), запускает приложение (ПР)
(для каждого клиента свое).
Надо :
Организовать передачу инфы от ПР к СК.
Можно ли использовать TServerClientThread из (СС) в
программе (ПР) или только
(ПР)-(WM_COPYDATA)->(CC)->(CК)

PS.Многопоточность в (СС) не предлагать . Работаю с BDE, а
оно (@-ка) при многопоточности работает не стабильно.

← →
Digitman © (2004-05-31 13:26) [1]

> Можно ли использовать TServerClientThread из (СС) в
> программе (ПР)

что это значит "использовать" ? поясни ..

← →
atruhin © (2004-05-31 13:27) [2]

А зачем использовать ? Можно ли использовать TServerClientThread из (СС)
Создавай сокет в твоей ПР и работай.

← →
half_litre (2004-05-31 13:32) [3]

>использовать
(ПР)->(CК), минуя (CC)

>Создавай сокет в твоей ПР и работай.
Тогда надо на (СК) ставить server + доп.порт выделять.

← →
Digitman © (2004-05-31 13:36) [4]

> half_litre (31.05.04 13:32) [3]
> >использовать
> (ПР)->(CК), минуя (CC)

а накой шут тогда СС нужен, если ПР у тебя "умеет" напрямую "общаться" с СК ?

← →
Polevi © (2004-05-31 13:38) [5]

можно попробовать передать хендл сокета в ПР

← →
half_litre (2004-05-31 13:46) [6]

>накой шут тогда СС нужен
А кто ж будет висет демоном и принимать заявки от (СС)
и запускать (ПР)

>можно попробовать передать хендл сокета в ПР
Вот это меня и интересовало, а нельзя ли с этого места
поподробнее plEEEEase

← →
atruhin © (2004-05-31 13:52) [7]

>>а накой шут тогда СС нужен, если ПР у тебя "умеет" напрямую >>"общаться" с СК ?
Видать диспетчер ПР, если ПР объемные и некоторые редко запускаются может и имеет смысл (стендартный сервер приложений).
>> Тогда надо на (СК) ставить server + доп.порт выделять.
А что один порт так жалко? Да и необязательно. Например клиет запустился зделал запрос СС получил ответ о успешном запуске ПР и коннектиться к ней.

← →
atruhin © (2004-05-31 13:55) [8]

>можно попробовать передать хендл сокета в ПР
и что N прграмм ПР будет работать через сокет сервера CC, а вопросы синхронизации. Это сколько гемора будет ?

← →
Digitman © (2004-05-31 13:58) [9]

> А кто ж будет висет демоном и принимать заявки от (СС)
> и запускать (ПР)

так вот задача этого самого "демона" (СС) - по той или иной технологии вести обмен данными с ПР (передавать запросы от СК к ПР и возвращать результаты запросов от ПР к СК)

а доп.трэды в составе СС-процесса здесь совершенно ни при чем : есть они или нет их - это не имеет отношения к протоколу инф.обмена между СС и СК, ровно так же как не имеют они отношения к протоколу инф.обмена между СС и ПР

трэды предназначены для параллельного выполнения длительных вычислений

← →
atruhin © (2004-05-31 14:07) [10]

>Digitman
Невсегда. Например в D6 для трехзвенки через сокеты входит утилита демон которая только запускает нужные программы по запросу а весь интерфейс предоставляет им.

← →
Digitman © (2004-05-31 14:07) [11]

> half_litre (31.05.04 13:16)

мне вообще непонятно : эти самые ПР - они "чужие" (готовые. без исх.текстов) или твоей разработки (с исх.текстами, алгоритм подконтролен и м.б. изменен в любой момент) ?

← →
Digitman © (2004-05-31 14:10) [12]

> atruhin © (31.05.04 14:07) [10]

это ты про Borland Socket Server что ли ?

← →
half_litre (2004-05-31 14:43) [13]

>эти самые ПР - они "чужие"
Мои

После запуска (ПР) на (СК) надо передать сообщения о
ходе выполнения задачи. Так можно ли обмануть природу и
детать это миную (CC) ?

← →
Polevi © (2004-05-31 16:10) [14]

procedure TForm1.FormCreate(Sender: TObject);
begin
ss.Active:=true;
end;

procedure TForm1.ssAccept(Sender: TObject;
Socket: TCustomWinSocket);
var
sa:TSecurityAttributes;
si:TStartupInfo;
pi:TProcessInformation;
cmdLine:string;
begin
//запускаем процесс и передаем ему хендл процесса и сокета
sa.nLength:=sizeof(TSecurityAttributes);
sa.bInheritHandle:=true;
sa.lpSecurityDescriptor:=nil;
GetStartupInfo(si);
si.cb:=sizeof(TStartupInfo);
cmdLine:=Format("D:\Prj\DupHandles\DupHandle.exe %d %d",[GetCurrentProcess,Socket.SocketHandle]);
if not CreateProcess(nil,PChar(cmdLine),nil,nil,true,0,nil,nil,si,pi) then
RaiseLastWin32Error;
end;

procedure TForm1.ssClientError(Sender: TObject; Socket: TCustomWinSocket;
ErrorEvent: TErrorEvent; var ErrorCode: Integer);
begin
ErrorCode:=0;
Socket.Close;
end;

код ПР

program duphandle;

{$APPTYPE CONSOLE}

uses
SysUtils,Windows,WinSock;

var
fromProcess, fromHandle, toHandle:Cardinal;
WSAData: TWSAData;
begin
{ TODO -oUser -cConsole Main : Insert code here }
try
fromProcess:=StrToInt(ParamStr(1)); //хендл процесса акцептора
fromHandle:=StrToInt(ParamStr(2)); //хендл сокета
//проецируем хендл сокета на текущий процесс
if not DuplicateHandle(fromProcess,fromHandle,GetCurrentProcess,@toHandle,0,false,DUPLICATE_SAME_ACCESS) then
RaiseLastOSError;

WSAStartup($0101, WSAData);
send(toHandle,PChar("Polevi the best")^,15,0);
WSACleanup;
except on E:Exception do
writeln(E.Message);
end;

readln;
end.

> half_litre (31.05.04 14:43) [13]
> >эти самые ПР - они "чужие"
> Мои

В таком случае ничто не мешает тебе разработать и реализовать ПИО между ПР и СС и использовать любой из удобных интерпроцессных коммуникационных механизмов (вин-сообщения, иненованые прогр.каналы, MMF и пр. и пр.)

> можно ли обмануть природу и
> детать это миную (CC) ?

зачем ?! СС на то и существует, чтобы заниматься централизованной диспетчеризацией/арбитражем инф.обмена удаленных клиентов со стартуемыми алгоритмами на стороне сервера !

в этом случае (когда ПР - твои) вообще непонятно, зачем оформлять некий алгоритм в виде отдельного приложения, а не в виде алгоритма в составе СС-приложения

СК послал запрос : расчитать то-то и то-то по таким-то параметрам

СС принял запрос, проанализировал его корректность и запустил отд.трэд в своем ВАП, передав ему параметры

доп.трэд выполнил задачу и известил СС о результатах ее выполнения

СС, получив от трэда результаты, передает их СК-клиенту

все !!

зачем извращаться со всякими ПР ?

намудрил я с DuplicateHandle , все проще гораздо

procedure TForm1.FormCreate(Sender: TObject);
begin
ss.Active:=true;
end;

procedure TForm1.ssAccept(Sender: TObject;
Socket: TCustomWinSocket);
var
sa:TSecurityAttributes;
si:TStartupInfo;
pi:TProcessInformation;
cmdLine:string;
begin
//запускаем процесс и передаем ему хендл сокета
sa.nLength:=sizeof(TSecurityAttributes);
sa.bInheritHandle:=true;
sa.lpSecurityDescriptor:=nil;
GetStartupInfo(si);
si.cb:=sizeof(TStartupInfo);
cmdLine:=Format("D:\Prj\DupHandles\DupHandle.exe %d",[Socket.SocketHandle]);
if not CreateProcess(nil,PChar(cmdLine),nil,nil,true,0,nil,nil,si,pi) then
RaiseLastWin32Error;
end;

procedure TForm1.ssClientError(Sender: TObject; Socket: TCustomWinSocket;
ErrorEvent: TErrorEvent; var ErrorCode: Integer);
begin
ErrorCode:=0;
Socket.Close;
end;

код ПР

program duphandle;

{$APPTYPE CONSOLE}

uses
SysUtils,Windows,WinSock;

var
toHandle:Cardinal;
WSAData: TWSAData;
begin
{ TODO -oUser -cConsole Main : Insert code here }
try
toHandle:=StrToInt(ParamStr(1)); //хендл сокета
WSAStartup($0101, WSAData);
send(toHandle,PChar("Polevi the best")^,15,0);
WSACleanup;
except on E:Exception do
writeln(E.Message);
end;

readln;
end.

а вообще я согласен с Digitman, такой способ мягко говоря не самый лучший

← →
half_litre (2004-05-31 16:54) [17]

>Digitman
с трэдями засада - BDE плохо переваривает multisession

>Polevi
(ПР) у меня не консольное приложение, могу ли я передать
из (СС) в (ПР) ссылку на обьект TServerClientThread
а в уже в (ПР) работать с ним как нормальным обьектом.

нет

и причем тут консольное

> half_litre (31.05.04 16:54) [17]
> с трэдями засада - BDE плохо переваривает multisession

полная ерунда

> (ПР) у меня не консольное приложение

да хоть сервис ! никакой разницы

> могу ли я передать
> из (СС) в (ПР) ссылку на обьект TServerClientThread
> а в уже в (ПР) работать с ним как нормальным обьектом.

ссылку на объект передать можешь, но вызывать методы/св-ва этого объекта ты можешь только в ВАП того процесса, который создал этот объект

p.s.

imho, у тебя такая страшная каша в голове из объектов, процессов, приложений, трэдов и прочих клиентов-серверов, что впору прекратить заниматься этим и засесть за теорию

Алгоритм обмена данными ? Найти похожие ветки