Конференция "Сети" » winsock, о приеме данных [D7, WinXP]
 
  • Сергей М. © (27.10.11 15:45) [40]

    > При обрыве связи, к примеру


    В TCP при обрыве ничего потеряться не может - все что успешно отправлено до момента обрыва, успешно и будет доставлено в той же последовательности.
  • Сергей М. © (27.10.11 15:50) [41]

    > такая кака не смотря ни на что все-таки возникала, при работе
    > со стандартным клиентом


    Эту каку подложил себе сам стандартный клиент, и TCP здесь совершенно ни причем.
    В поточном транспортном протоколе с квитированием доставки потери дейтаграмм, их искажения или нарушения последовательности их доставки попросту исключены.
  • Очень Злой (27.10.11 15:56) [42]

    > Эту каку подложил себе сам стандартный клиент, и TCP здесь
    > совершенно ни причем.
    > В поточном транспортном протоколе с квитированием доставки
    > потери дейтаграмм, их искажения или нарушения последовательности
    > их доставки попросту исключены.


    ну не знаю... Насчет потери - согласен, а вот насчет искажения... даже не знаю...
    А чем определяется искажены данные или нет?
    Если контрольной суммой, то она также может быть искажена вместе с данными и теоретически возможны случаи, когда искаженная контрольная сумма будет соответствовать искаженным данным...
  • Сергей М. © (27.10.11 16:04) [43]

    > а вот насчет искажения


    Искажения на уровнях ниже прикладного отсечет сам стек TCP/IP.
    А за контроль искажений на прикладном уровне ответственны сами обменивающиеся прикладные стороны.
  • Anatoly Podgoretsky © (27.10.11 16:06) [44]
    > Очень Злой  (27.10.2011 15:56:42)  [42]

    Зачем контрольная сумма, MD5 хеш, CRC64, коды хеминга
  • Сергей М. © (27.10.11 16:07) [45]

    > чем определяется искажены данные или нет?


    Ну как чем ?
    Если принятые данные не соответствуют прикладному протоколу, значит они искажены.
    При идеальном прикл.следовании протоколу сос тороны приемника винить в искажении можно только либо передатчик либо "человека посередине". Либо и того и другого одновременно)
  • Сергей М. © (27.10.11 16:07) [46]

    > чем определяется искажены данные или нет?


    Ну как чем ?
    Если принятые данные не соответствуют прикладному протоколу, значит они искажены.
    При идеальном прикл.следовании протоколу сос тороны приемника винить в искажении можно только либо передатчик либо "человека посередине". Либо и того и другого одновременно)
  • han_malign (27.10.11 17:06) [47]

    > контрольная сумма, MD5 хеш, CRC64, коды хеминга

    - обычно достаточно контроля несущей(CSMA/CD), сбои ЦАП/АЦП относятся уже к условиям ядерной войны(либо феноменальной жадности при прокладке сегмента) - если не хватает 32-бит CRC Ethernet-пакета и 16-бит контрольной суммы TCP(не считая приличного количества контекстно-фиксированных бит в заголовках) - то спасет только тройное дублирование...
  • Slym © (28.10.11 08:25) [48]
    забудь про пакеты! для пользователя TCP-это поток данных, контроль над порядком и целостностью лежит на системе, потеряться или измениться порядок без злоумышленника не может
  • Slym © (28.10.11 08:28) [49]
    Очень Злой   (27.10.11 12:29) [29]
    В блоке я даже и не представляю пока как это сделать...

    как раз твоя писанина и напоминает блочную работу, но сокет установлен в неблок - и это не правильно
    в неблоке никаких ReceivePackets не должно быть, а должно быть OnRead и OnWrite
  • Slym © (28.10.11 09:21) [50]
    примерно так
    type
     TMyProtoReader=class
     private
       Socket:TClientSocket;
       Packet:Pointer;
     public
       constructor Create;
       destructor Destroy;override;
       function Connect:boolean;
       function GetPacket:Pointer;
     end;

    { TMyProtoReader }

    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;

  • han_malign (28.10.11 11:16) [51]

    > напоминает блочную работу, но сокет установлен в неблок - и это не правильно

    - приберегите свой свою категоричность(и откровенный говнокод) до времен - когда поймете что (non)blocking - означает (не)блокирующий, а не "блочный"...

    Блокирующий режим может быть использован в крайне ограниченном количестве сценариев - когда до получения определенного набора данных дальнейшее функционирование приложения невозможно...
    И при этом циклами не заморачиваются, а используют асинхронный ReadFile или асинхронный WSARecv...
  • Slym © (28.10.11 14:24) [52]
    han_malign   (28.10.11 11:16) [51]
    покажи пример неблочного режима и сравни с тем что Очень злой господин пишет...
    а пишет он неблокирующий сокет в блокирующей манере - где хоть одно сообщение OnRead?
    han_malign   (28.10.11 11:16) [51]
    Блокирующий режим может быть использован в крайне ограниченном количестве сценариев

    кто тебе сказал? Сокеты Беркли - блокирующие, весь линух на них, а микрософт к ним прицепил нативную для винды асинхронную модель сообщений
    есть один сценарий неприменимый для влоб блочного режима - высоконагруженный многоклиентский сервер где ограничение в колве потоков
    клиентскому сокету побарабану блок/неблок монописуально 1 поток
  • Slym © (28.10.11 14:27) [53]
    han_malign   (28.10.11 11:16) [51]
    приберегите свой свою категоричность(и откровенный говнокод) до времен - когда поймете что (non)blocking - означает (не)блокирующий, а не "блочный"...

    напиши на данную тему в неблокирующей манере свой пример и посмотрим чей код говнее
  • han_malign (28.10.11 17:15) [54]

    > где хоть одно сообщение OnRead?
    ...
    > Сокеты Беркли - блокирующие, весь линух на них

    - ссылку пожалуйста, на отсутствие неблокирующего режима в сокетах Беркли...

    > и посмотрим чей код говнее

    - Вы будете спорить, что код вешающий приложение до следующего входящего пакета и вываливающий исключение, если оно не пришло в течение getsockopt(SO_RCVTIMEO) - плохо пахнет?
  • Сергей М. © (28.10.11 19:56) [55]

    > микрософт к ним прицепил нативную для винды асинхронную
    > модель сообщений


    Он ее прицепил опираясь именно на неблокирующий режим как один из классических режимов гнезд Беркли)

    В Пердивикии по этому поводу есть, кстати, заметка:

    http://en.wikipedia.org/wiki/Berkeley_sockets#Blocking_vs._non-blocking_mode
  • Slym © (31.10.11 05:18) [56]
    han_malign   (28.10.11 17:15) [54]
    - Вы будете спорить, что код вешающий приложение до следующего входящего пакета и вываливающий исключение, если оно не пришло в течение getsockopt(SO_RCVTIMEO) - плохо пахнет?

    продолжаем обсирать... на этот раз обделан код никак не связаный с сабжом сокетами...
    СЛИВ ЗАСЧИТАН...
  • Slym © (31.10.11 05:24) [57]
    Сергей М. ©   (28.10.11 19:56) [55]
    тут я погорячился... примеров unix+nonblock я не встречал вот и сделал неправильный вывод
  • Очень Злой (31.10.11 11:11) [58]

    > в неблоке никаких 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;




    разве это в "блокирующей манере"?
  • Slym © (31.10.11 12:03) [59]
    Очень Злой   (31.10.11 11:11) [58]
    WSAAsyncSelect

    первое упоминание AsyncSelect...
 
Конференция "Сети" » winsock, о приеме данных [D7, WinXP]
Есть новые Нет новых   [134435   +20][b:0][p:0.002]