-
> При обрыве связи, к примеру
В TCP при обрыве ничего потеряться не может - все что успешно отправлено до момента обрыва, успешно и будет доставлено в той же последовательности.
-
> такая кака не смотря ни на что все-таки возникала, при работе > со стандартным клиентом
Эту каку подложил себе сам стандартный клиент, и TCP здесь совершенно ни причем. В поточном транспортном протоколе с квитированием доставки потери дейтаграмм, их искажения или нарушения последовательности их доставки попросту исключены.
-
> Эту каку подложил себе сам стандартный клиент, и TCP здесь > совершенно ни причем. > В поточном транспортном протоколе с квитированием доставки > потери дейтаграмм, их искажения или нарушения последовательности > их доставки попросту исключены.
ну не знаю... Насчет потери - согласен, а вот насчет искажения... даже не знаю... А чем определяется искажены данные или нет? Если контрольной суммой, то она также может быть искажена вместе с данными и теоретически возможны случаи, когда искаженная контрольная сумма будет соответствовать искаженным данным...
-
> а вот насчет искажения
Искажения на уровнях ниже прикладного отсечет сам стек TCP/IP. А за контроль искажений на прикладном уровне ответственны сами обменивающиеся прикладные стороны.
-
> Очень Злой (27.10.2011 15:56:42) [42]
Зачем контрольная сумма, MD5 хеш, CRC64, коды хеминга
-
> чем определяется искажены данные или нет?
Ну как чем ? Если принятые данные не соответствуют прикладному протоколу, значит они искажены. При идеальном прикл.следовании протоколу сос тороны приемника винить в искажении можно только либо передатчик либо "человека посередине". Либо и того и другого одновременно)
-
> чем определяется искажены данные или нет?
Ну как чем ? Если принятые данные не соответствуют прикладному протоколу, значит они искажены. При идеальном прикл.следовании протоколу сос тороны приемника винить в искажении можно только либо передатчик либо "человека посередине". Либо и того и другого одновременно)
-
> контрольная сумма, MD5 хеш, CRC64, коды хеминга
- обычно достаточно контроля несущей(CSMA/CD), сбои ЦАП/АЦП относятся уже к условиям ядерной войны(либо феноменальной жадности при прокладке сегмента) - если не хватает 32-бит CRC Ethernet-пакета и 16-бит контрольной суммы TCP(не считая приличного количества контекстно-фиксированных бит в заголовках) - то спасет только тройное дублирование...
-
забудь про пакеты! для пользователя TCP-это поток данных, контроль над порядком и целостностью лежит на системе, потеряться или измениться порядок без злоумышленника не может
-
Очень Злой (27.10.11 12:29) [29] В блоке я даже и не представляю пока как это сделать... как раз твоя писанина и напоминает блочную работу, но сокет установлен в неблок - и это не правильно в неблоке никаких ReceivePackets не должно быть, а должно быть OnRead и OnWrite
-
примерно так type
TMyProtoReader=class
private
Socket:TClientSocket;
Packet:Pointer;
public
constructor Create;
destructor Destroy;override;
function Connect:boolean;
function GetPacket:Pointer;
end;
constructor TMyProtoReader.Create;
begin
Socket:=TClientSocket.Create(nil);
Socket.ClientType:=ctBlocking;
end;
destructor TMyProtoReader.Destroy;
begin
Socket.Free;
FreeMem(Packet);
inherited;
end;
function TMyProtoReader.Connect: boolean;
begin
Socket.Address:='127.0.0.1';
Socket.Port:=12345;
Socket.Active:=true;
result:=Socket.Active;
end;
function TMyProtoReader.GetPacket: Pointer;
type
PPacket=^TPacket;
TPacket=packed record
Len:word;
data:array[0..0] of byte;
end;
function RecvBufFully(Peer:TCustomWinSocket;var Buf; Count: Integer):boolean;
var pBuf:PByte;
s:integer;
begin
result:=false;
pBuf:=@Buf;
while count>0 do
begin
s:=Peer.ReceiveBuf(pBuf^,Count);
if s=0 then exit;
inc(pBuf,s);
dec(Count,s);
end;
result:=true;
end;
var len:word;
begin
if not Socket.Active then
raise Exception.Create('Not connected');
if not RecvBufFully(Socket.Socket,len,SizeOf(len)) then
begin
Socket.Active:=false;
raise Exception.Create('Bad packet');
end;
ReallocMem(Packet,len);
PPacket(Packet).Len:=len;
if not RecvBufFully(Socket.Socket,PPacket(Packet).Data,PPacket(Packet).len) then
begin
Socket.Active:=false;
raise Exception.Create('Bad packet');
end;
result:=Packet;
end;
procedure TForm1.Button1Click(Sender: TObject);
var
reader:TMyProtoReader;
Packet:pointer;
begin
reader:=TMyProtoReader.Create;
try
reader.Connect;
while true do
begin
Packet:=reader.GetPacket;
ProcessPacket(Packet);
Application.ProcessMessages;
end;
finally
reader.Free;
end;
end;
-
> напоминает блочную работу, но сокет установлен в неблок - и это не правильно
- приберегите свой свою категоричность(и откровенный говнокод) до времен - когда поймете что (non)blocking - означает (не)блокирующий, а не "блочный"...
Блокирующий режим может быть использован в крайне ограниченном количестве сценариев - когда до получения определенного набора данных дальнейшее функционирование приложения невозможно... И при этом циклами не заморачиваются, а используют асинхронный ReadFile или асинхронный WSARecv...
-
han_malign (28.10.11 11:16) [51] покажи пример неблочного режима и сравни с тем что Очень злой господин пишет... а пишет он неблокирующий сокет в блокирующей манере - где хоть одно сообщение OnRead? han_malign (28.10.11 11:16) [51] Блокирующий режим может быть использован в крайне ограниченном количестве сценариев кто тебе сказал? Сокеты Беркли - блокирующие, весь линух на них, а микрософт к ним прицепил нативную для винды асинхронную модель сообщений есть один сценарий неприменимый для влоб блочного режима - высоконагруженный многоклиентский сервер где ограничение в колве потоков клиентскому сокету побарабану блок/неблок монописуально 1 поток
-
han_malign (28.10.11 11:16) [51] приберегите свой свою категоричность(и откровенный говнокод) до времен - когда поймете что (non)blocking - означает (не)блокирующий, а не "блочный"... напиши на данную тему в неблокирующей манере свой пример и посмотрим чей код говнее
-
> где хоть одно сообщение OnRead? ... > Сокеты Беркли - блокирующие, весь линух на них
- ссылку пожалуйста, на отсутствие неблокирующего режима в сокетах Беркли...
> и посмотрим чей код говнее
- Вы будете спорить, что код вешающий приложение до следующего входящего пакета и вываливающий исключение, если оно не пришло в течение getsockopt(SO_RCVTIMEO) - плохо пахнет?
-
-
han_malign (28.10.11 17:15) [54] - Вы будете спорить, что код вешающий приложение до следующего входящего пакета и вываливающий исключение, если оно не пришло в течение getsockopt(SO_RCVTIMEO) - плохо пахнет? продолжаем обсирать... на этот раз обделан код никак не связаный с сабжом сокетами... СЛИВ ЗАСЧИТАН...
-
Сергей М. © (28.10.11 19:56) [55] тут я погорячился... примеров unix+nonblock я не встречал вот и сделал неправильный вывод
-
> в неблоке никаких ReceivePackets не должно быть, а должно > быть OnRead и OnWrite
> а пишет он неблокирующий сокет в блокирующей манере - где > хоть одно сообщение OnRead?
Почему? ...
procedure SocketEvent(var M:TMessage); message WM_SOCKET_AUTH_EVENT;
...
if WSAAsyncSelect(FSocket,FWindowHandle,WM_SOCKET_AUTH_EVENT, FD_CONNECT or FD_READ or FD_WRITE or FD_CLOSE)= SOCKET_ERROR then
...
procedure TXXX.SocketEvent(var M:TMessage);
begin
case M.LParam of
FD_CONNECT:;
FD_READ: ReceivePackets;
FD_WRITE: SendPackets;
FD_CLOSE: CloseConnection;
end;
end;
разве это в "блокирующей манере"?
-
Очень Злой (31.10.11 11:11) [58] WSAAsyncSelect первое упоминание AsyncSelect...
|