Организация управления прог в сети. Как лучше реализовать?

← →
Calm (2003-10-17 10:55) [0]

Необходимо разработать серверное приложение и клиентские проги.
Сервер должен управлять клиентами - посылать им команды и данные. Объем посылок небольшой - не более 40-60 байт.

Как проще реализовать subj? Опыта работы с сетями маловато :( , поэтому прошу совета.
Можно использовать сокеты TServerSocket и TClientSocket, но там не гарантируюется, что один вызов метода отправки сообщения клиенту сгенерирует одно событие чтения на клиенте. Конечно можно реализовать подтверждения приема/отпраки, но есть подозрение, что это уже где-то давно реализовано.
Я прав? Если да, то подскажите, какие компоненты мне следует использовать.

Заранее благорен за все советы :)

← →
Reindeer Moss Eater (2003-10-17 10:57) [1]

Конечно можно реализовать подтверждения приема/отпраки, но есть подозрение, что это уже где-то давно реализовано.

В TCP протоколе давно.

← →
Calm (2003-10-17 11:02) [2]

Давно-то давно, но
если два раза подряд отправить клиенту текст с помощью компонента TServerSocket, то на клиенте произойтет одно событие чтения.

← →
Calm (2003-10-17 11:03) [3]

Проблема не в передачи пакетов по сети, а в организации логики клиентской проги.

Хочется иметь на один вызов команды записи на сервере одно событие чтения на клиенте.

← →
Reindeer Moss Eater (2003-10-17 11:10) [4]

Хочется иметь на один вызов команды записи на сервере одно событие чтения на клиенте.

1. Мало ли чего хочется.
2. Зачем вообще использовать события (асинхронный режим) если не хочется их грамотно обрабатывать?

← →
Calm (2003-10-17 11:41) [5]

Мне кажется, уважаемый Reindeer Moss Eater,
что в корректной форме ваш ответ должен был выглядеть примерно так:

> Конечно можно реализовать подтверждения приема/отпраки,
> но есть подозрение, что это уже где-то давно реализовано.
>
> Я прав?

Нет, не реализовано. Ты не прав. Обычно делают так-то.

[4] - это элементарное хамство.

← →
Verg (2003-10-17 11:48) [6]

> Calm © (17.10.03 11:02) [2]
> Давно-то давно, но
> если два раза подряд отправить клиенту текст с помощью
> компонента TServerSocket, то на клиенте произойтет одно
> событие чтения.

А может и три произойти и что?

И ничего. Это обычная, совершенно нормальная практика, когда производится "сборка" принятых фрагментов до наступления какого-то заранее оговоренного события,
Например, когда в собираемой строке символов встречается перевод строки (#13#10)

Серверу достаточно передавать текстовЫе строки-комады как SendText(StringToSend+#13#10)
а
клиенту в OnRead производить сборку и отслеживать появления заданной комбинации символов:

TFOR1m = class(TForm)
......
ReceivedString : string;
end;

procedure TForm1.ClientSocket1Read(Sender: TObject;
Socket: TCustomWinSocket);
var B : string;
Rcv, Len : integer;
begin
SetLength(B, 1024);
Rcv:=Socket.ReceiveBuf(B[1], length(B));
while Rcv>0 do
begin
ReceivedString:=ReceivedString+Copy(B, 1 , Rcv);
Len:=Pos(#13#10, ReceivedString);
if len>0 then
begin
Copy(ReceivedString, 1, Len-1); // Это очередная принятая строка - делай с не все, что тебе надо
Delete(ReceivedString, 1, len+1)
end;
Rcv:=Socket.ReceiveBuf(B[1], length(B));
end;
end;

В протоколах основанных не на текстовом представлении обычно контролируют размер накопленной при приеме информации пока он не станет удовлетворять минимальному или контекстно-корректному значению.

Протокол взаимодействия необходимо реализовывать, если по условиям протокола сервер(клиент) не имеет права посылать следующую команду до тех пор, пока клиент(сервер) не обработает текущую.
Пример - да хоть SMTP протокол, RFC821

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

Ну, а если ты увидел в этом какую-то катострофическую проблему, то и заниматься тебе этим еще просто рановато....

← →
Calm (2003-10-17 11:55) [7]

> А может и три произойти и что?

Мастера, да я же не спорю с этим!!!

> Ну, а если ты увидел в этом какую-то катострофическую проблему,
> то и заниматься тебе этим еще просто рановато....

Да нет, ничего катосрофического, просто думал, что может есть какой-будь общеизвестный компонент, которые производит описанную вами сборку.
А то, что в этом деле я еще не очень силен, я не скрываю.

P.S. Verg, большое спасибо за подробный ответ.

← →
Reindeer Moss Eater (2003-10-17 12:02) [8]

Тебе же сказали если не хочется обрабатывать события - не используй асинхронный режим и не парься.

← →
Calm (2003-10-17 12:20) [9]

Ok, попробую.

Организация управления прог в сети. Как лучше реализовать? Найти похожие ветки