чтение сокета. ServerSocket1ClientRead

← →
Цукор5 (2010-06-14 23:46) [0]

Отсылаю некоторую структуру по сети, используя компонент TClientSocket и принимаю ее же компонентом TServerSocket.
Предположим, так :
type TIndMsg = packed record Start : Byte; Mode : Byte; Addr : Byte; Value : Word; Stop : Byte; end; PIndMsg = ^TIndMsg; procedure TForm1.Button1Click(Sender: TObject); var Ind:TIndMsg; begin Ind.Start := $0A; Ind.Mode := RandomRange(1,10); Ind.Addr := $05; Ind.Value := $01; Ind.Stop := $0D; ClientSocket1.Socket.SendBuf(Ind,SizeOf(TIndMsg)); end; procedure TForm1.ServerSocket1ClientRead(Sender: TObject; Socket: TCustomWinSocket); var N:Integer; Ind:TIndMsg; begin N:=Socket.ReceiveLength; if N>=SizeOf(TIndMsg) then begin Socket.ReceiveBuf(Ind,SizeOf(TIndMsg)); //Memo1.Lines.Add(IntToStr( Ind.Value )); смотрю что пришло end; end;

Все хорошо. Все работает. Но!!!Используемый мною режим stNonBlocking. Я правильно понимаю, что НЕТ никаких гарантий, что пакет прийдет именно моего размера?
Он может прийти как угодно.
Например так:
-0A 02
-05 00 01 0D
или так (сразу придет 2 пакета)
-0A 02 05 00 01 0D 0A 07 05 00 01 0D

И лучше, например, принимать по-байтно. Далее контролировать условия пакета и если оно выполнено, то только тогда наполнять структуру TIndMsg.
Я верно рассуждаю?

Заранее спасибо!

← →
KilkennyCat © (2010-06-15 00:44) [1]

> Используемый мною режим stNonBlocking. Я правильно понимаю,
> что НЕТ никаких гарантий, что пакет прийдет именно моего
> размера?

Неправильно. Этот режим всего лишь не блокирует выполнение кода, на размер пакета не влияет.

← →
Цукор5 (2010-06-15 00:57) [2]

2 KilkennyCat © (15.06.10 00:44) [1]
Хм...странно. Вот нашел на Королевстве: http://www.delphikingdom.ru/asp/answer.asp?IDAnswer=51444

Цитата А.Григорьева : Протокол TCP допускает склеивание пакетов в один, т.е. то, что вы отправляли за несколько Send"ов, может быть получено одним Receive"ом

← →
Германн © (2010-06-15 01:03) [3]

> Неправильно. Этот режим всего лишь не блокирует выполнение
> кода, на размер пакета не влияет.

Хм. А ты уверен? Асинхронная работа при приёме/передаче не может не "дробить" на куски длинный блок данных, имхо.

← →
Германн © (2010-06-15 01:06) [4]

> Цукор5 (15.06.10 00:57) [2]

И это тоже верно.
Т.е. в любом случае нужно принимать столько данных, сколько получено. Складывать эти данные в некий буфер, анализировать содержимое буфера и по результатам анализа решать что делать.

← →
Цукор5 (2010-06-15 01:13) [5]

2 Германн © (15.06.10 01:06) [4]

Ок. Спасибо.

← →
KilkennyCat © (2010-06-15 01:16) [6]

> Асинхронная работа при приёме/передаче не может не "дробить"
> на куски длинный блок данных, имхо.

да пофиг. есть начало данных, есть конец данных, а какой кучей они пришли - неважно.

← →
Германн © (2010-06-15 02:45) [7]

> Цукор5 (14.06.10 23:46)

Хм. Интересный выбор признаков начала и конца блока посылки.
Ну тут уж АП - мастер.

← →
Сергей М. © (2010-06-15 10:11) [8]

> Я правильно понимаю, что НЕТ никаких гарантий, что пакет
> прийдет именно моего размера?

Да, правильно.
Но non-blocking-режим здесь совершенно ни причем.

← →
Вариант (2010-06-15 10:39) [9]

> Германн © (15.06.10 01:06) [4]

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

← →
balepa (2010-06-15 13:47) [10]

CRC можно добавить.

зачем?

чтение сокета. ServerSocket1ClientRead Найти похожие ветки