Ускорение обменом сообщениями

← →
grvakh (2002-10-15 11:13) [0]

Есть 2 машины, обменивающиеся малыми(<1 кб) даными. Сделано это на сокетах (Tserver|client socket). Особенностью задачи является поочередность отсылки: шлет одна и ждет прихода инф. с другой.
Какими методами, способами, настройками можно сей процесс ускорить? 2 канала (один - в одну, др - в др. сторону) уже пробовал...

grvakh

← →
Digitman (2002-10-15 12:14) [1]

А в чем проявляется замедление "сего процесса", по твоему мнению ?

← →
grvakh (2002-10-15 16:17) [2]

Когда данные идут в одну сторону - скорость работы более чем на порядок(sic!) выше, чем при ожидании подтверждения. :-(. Чем тут можно поиграть?Размерами пакета? Но обратно я отсылаю longint и всё. Thread -ами? (я пока без них). HAL как-то делает ведь.

c уважением
grvakh

← →
Digitman (2002-10-15 17:10) [3]

sic - это что ? сИкунды ?)
HAL - это что ? hardware abstraction layer ? он здесь ни при чем

thread"ы не дают никакого "ускорения" - вычисления в доп. thread"ах просто разгружают осн.поток (задача которого как правило - интерфейс взаимодействия с пользователем)

Приводи код приемника/передатчика

← →
grvakh (2002-10-16 09:47) [4]

---------
На стороне клиента

procedure TForm1.ClientSocketRead(Sender: TObject; Socket: сustomWinSocket);
var i,e:integer; w:longint;
begin w:=5757;
i:=socket.ReceiveLength;
if (nsrv =0) or (i=sizeof(nsrv)) then begin
i:=Socket.ReceiveBuf(nsrv,sizeof(nsrv));
exit;
end;
if i>8192 then begin
st2.Caption:="Buffer owerflow";
end; // Bufer overflow

i:=Socket.ReceiveBuf(par,sizeof(Array)*nsrv);

if i<0 then exit;
{ Здесь - обработка информации }
....
{ Здесь - обработка информации }

for i := 0 to Ss_OS.Socket.ActiveConnections-1 do
SS_OS.Socket.Connections[i].SendBuf(w,sizeof(w));
// Здесь - реализована "обратная связь. По идее, надо тоже клиентом
// А то небольшой изврат :(
end; { proc }
=================
На стороне сервера
procedure TForm1.btStartClick(Sender: TObject);
var i,j,e:integer;w:array[1..1024] of longint;
begin
if Ss_t.Socket.ActiveConnections=0 then exit;
if (not CS.active)and assigned(ss_t.Socket.Connections[0]) then begin
// Запускаем "клиента"
cs.Host :=ss_t.Socket.Connections[0].RemoteAddress;//ss_t.Socket.Connections[0].RemoteHost;
cs.Port := 7007;
{Пытаемся соединиться}
try cs.Open; except exit; end;
exit;
end;
for i := 0 to Ss_T.Socket.ActiveConnections-1 do begin
e:=SS_T.Socket.Connections[i].ReceiveLength;
if e>0 then
try e:=SS_T.Socket.Connections[i].ReceiveBuf(w,e);
except e:=0 end;
end; { for }

for i := 0 to Ss_T.Socket.ActiveConnections-1 do
SS_T.Socket.Connections[i].SendBuf(nsrv,sizeof(nsrv));
i:=0;
repeat
for j := 0 to Ss_T.Socket.ActiveConnections-1 do
e:=SS_T.Socket.Connections[i].Sendbuf(par,sizeof(array)*nsrv);
if e<0 then begin
statusbar1.simpletext:="Ошибка передачи данных !";
end;
//Собственно вычисления
....
//Собственно вычисления
repeat Application.ProcessMessages;
until clientConfirm;
inc(i);
until i>100000;
end;
Обратная связь - в отдельном "канале".
procedure TForm1.CSRead(Sender: TObject; Socket: TCustomWinSocket);
var w:longint; e:integer;
begin w:=0;
e:=socket.ReceiveBuf(w,4);
clientconfirm:= w=5757;
end;
--------------------------------

← →
Polevi (2002-10-16 10:06) [5]

каша

← →
grvakh (2002-10-16 10:15) [6]

Ну, есть конечно каша...Но в принципе-то!
А HAL - это одна из систем распределенного имитационного моделирования. Тренажеры. Sic - Так! (лат.) - т.е. "Даже вот так! ни ф... себе!" Извиняюсь за термины, не относящиеся к делу - привычка.

------

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

1. Очень некорректно реализована обработка транспортных событий OnRead. Посмотри, как это сделано в демо-проекте scktsrvr.dpr.

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

← →
grvakh (2002-10-16 13:25) [8]

1. try try try ...я по-частям решаю эффективность/надежность, стараюсь не гнаться за 2 зайцами. Пример - спасибо, ознакомляюсь.
2 Т.е. самое лучшее - сделать задачу многопоточной?

← →
Digitman (2002-10-16 13:48) [9]

1. <Polevi> оч верно заметил : каша у тебя... разгребай и дели обработчик трансп.события на логически четкие и независимые субблоки - машина состояния, выборка из вх.потока, анализ на корректность и т.п.

2. Не всегда и не "самое лучшее", но достаточно оправданно в случаях длительной обработки поступающих запросов

← →
grvakh (2002-10-16 15:19) [10]

Спасибо!

← →
grvakh (2002-10-16 15:40) [11]

А если многопоточность-то каким путём: stThreadBlocking или породить отдельный поток для вычислений?

← →
Digitman (2002-10-16 15:51) [12]

А как угодно ! Суть от этого не меняется.
Просто stThreadBlocking-режим чуть облегчает задачу, ибо часть логики контроля за созданием/кэшированием/старт-стопом/уничтожением доп.потоков берет на себя класс TServerWinSocket.

С другой стороны скажу, что stThreadBlocking-режим введен Борландом в 1-ю очередь для выноса в доп.поток транспортного уровня коннекта, а не для бизнес-логики, реализующей обработку запросов ...

Ускорение обменом сообщениями Найти похожие ветки