Текущий архив: 2010.09.12;
Скачать: CL | DM;
Вниз
чтение сокета. 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 можно добавить.
← →
KilkennyCat © (2010-06-15 17:52) [11]зачем?
Страницы: 1 вся ветка
Текущий архив: 2010.09.12;
Скачать: CL | DM;
Память: 0.49 MB
Время: 0.009 c
