• kashey © (15.11.18 16:30) [0]
    Подскажите пожалуйста, кто работал с этой библиотекой, как правильно читать данные?
    Данные которые приходят, имеют такой формат:
    5#0Hello#0, т.е. в начале число байт #0 строка этой длинны #0

    Из примеров нарыл только этот в демках:

    procedure TRecvForm.ClientDataAvailable(Sender : TObject; Error : Word);
    var
       Buf : array [0..127] of AnsiChar;
       Len : Integer;
    begin
       Len := TWSocket(Sender).Receive(@Buf, Sizeof(Buf) - 1);
       if Len <= 0 then
           Exit;
       { Remove any trailing CR/LF}
       while (Len > 0) and (Buf[Len - 1] in [ #13, #10]) do
           Dec(Len);
       { Nul terminate the data }
       Buf[Len] := #0;
       Display('DataAvailable: ''' + String(Buf) + '''');
    end;



    Читал еше просто через ReceiveStr. Всегда получаю только кусок текста с конца, по размерам примерно половину от всего что нужно получить, начальная часть теряется. Подскажите почему так?
  • DayGaykin © (15.11.18 17:22) [1]
    Потому что протокол передачи данных у тебя такой. TWSocket не причем
  • kashey © (15.11.18 17:44) [2]
    Какой протокол, я не знаю (реализация клиента не моя). Но в инди IdTCPserver я читал очень просто: Ch := AContext.Connection.IOHandler.ReadChar() пока Ch <> #0
  • han_malign © (16.11.18 13:17) [3]

    > очень просто: Ch := AContext.Connection.IOHandler.ReadChar()

    если тупо:
    Len := TWSocket(Sender).Receive(@Ср, 1);
    классический накопительный FIFO(размер буфера заведомо больше максимально размера сообщения):
    Len := TWSocket(Sender).Receive(@F_rgchBuf{поле класса}[F_cchBufDepth{поле класса}], sizeof(F_rgchBuf) - F_cchBufDepth);
    if( len <= 0 )then
      exit;
    inc(F_cchBufDepth, len);
    cchExtracted:= 0;
    try
      while( cchExtracted < F_cchBufDepth )do begin
         cchWholeNdrMessagePacket:= adjustMyProtoWholeMessage{_AndProcess}(@F_rgchBuf[cchExtracted], F_cchBufDepth - cchExtracted{, ...}); { return 0 for incompleted message part, < 0 for broken stream
         if( cchWholeNdrMessagePacket < 0 )then // (TO)DO: drop connection with broken stream(see (try finally) remark)
            raise ENotSupportedException;
         if( cchWholeNdrMessagePacket = 0 )then // no more whole messages, keep leading part and wait continue
            break;
         inc( cchExtracted, cchWholeNdrMessagePacket );
      end;
    finally // (try finally): just for case when ENotSupportedException wouldn`t drop connection(i.e. protocol supports error reporting and stream repair)
      if( cchExtracted > 0 )then begin //pack buffer
         dec( F_cchBufDepth, cchExtracted );
         if( F_cchBufDepth > 0 )then // has incompleted(or broken) message part
            move(F_rgchBuf[cchExtracted], F_rgchBuf[0], F_cchBufDepth);
      end;
    end;
  • kashey © (18.11.18 21:36) [4]
    Слава Богу пришлось бросить Indy, а то я думал с ума сойду с ее много поточной системой. Единственный плюс - примерно понял как оно работает. В ics все и всегда в основном потоке? Тогда и таймерочками побаловаться неверное можно для ожидания данных?
  • Германн © (19.11.18 02:23) [5]

    > В ics все и всегда в основном потоке?

    Не всё и не всегда. Но в потроха ICS вам пока рано лазить.
  • Германн © (19.11.18 02:31) [6]

    > Тогда и таймерочками побаловаться неверное можно для ожидания
    > данных?

    А вот это уже не ics. ICS работает по событиям.
  • Eraser © (19.11.18 02:39) [7]

    > kashey ©   (18.11.18 21:36) [4]

    ICS это кривая библиотека, которая не держит нагрузки и плохо написана.
    в наше время имеют право на жизнь два подхода:
    1. Indy (или подобные) библиотеки с синхронной моделью. Основной плюс - простота использования, можно легко написать любой протокол и разобраться в существующих, легко цепляется openssl.
    2. IOCP (epoll под линукс) - это асинхронный и довольно сложный подход, но обеспечивает огромную, в плане одновременно работающих соединений, производительность.

    все остальное не имеет право на жизнь в новых проектах, только legacy.
  • Германн © (19.11.18 03:00) [8]

    > Eraser ©   (19.11.18 02:39) [7]

    Лёша, ты можешь подкрепить твою нелюбовь к библиотеке ICS реальными данными?
  • Eraser © (19.11.18 03:44) [9]

    > Германн ©   (19.11.18 03:00) [8]

    конечно, испытывал ее в свое время. она годится разве что какой-нибудь клиент написать. для серверов с несколькими тысячами соединений она не годится, а на десятках тысяч даже испытывать не стал. если нужен сервер на 1000-2000 соединений, то не нужно изобретать велосипед со сложной асинхронной логикой, а заюзать Indy.
  • kashey © (19.11.18 08:51) [10]

    > Германн ©   (19.11.18 02:31) [6]
    >
    > > Тогда и таймерочками побаловаться неверное можно для ожидания
    >
    > > данных?
    >
    > А вот это уже не ics. ICS работает по событиям.

    Я немного не в том смысле. Я о том, что можно таймером можно делать повторные запросы, если по какой-то причине не получил того что ждал.  


    > Eraser ©   (19.11.18 02:39) [7]
    >
    > > kashey ©   (18.11.18 21:36) [4]
    >
    > ICS это кривая библиотека, которая не держит нагрузки и
    > плохо написана.

    Не понятно вообще кого слушать, ну давайте тогда уж реальные примеры плохой работы.
  • kashey © (19.11.18 08:55) [11]

    > то не нужно изобретать велосипед со сложной асинхронной
    > логикой, а заюзать Indy.

    Попробуйте слушать сервером порт, подключить к нему несколько клиентов, а затем в конце  корректно остановить сервер (те. после отключения всех клиентов установить для сервера Active := False). Куча проблем на ровном месте из-за многопоточности
  • Германн © (21.11.18 02:47) [12]

    > Eraser ©   (19.11.18 03:44) [9]
    >
    >
    > > Германн ©   (19.11.18 03:00) [8]
    >
    > конечно, испытывал ее в свое время. она годится разве что
    > какой-нибудь клиент написать. для серверов с несколькими
    > тысячами соединений она не годится, а на десятках тысяч
    > даже испытывать не стал. если нужен сервер на 1000-2000
    > соединений, то не нужно изобретать велосипед со сложной
    > асинхронной логикой, а заюзать Indy.
    > kashey ©   (19.11.18 08:51) [10]

    Ну понятно. Тут не столько претензии к библиотеке и к её автору. Сколько к разработчикам Windows, которые обещали нормальную работу с событиями, но не смогли её реализовать в достаточной мере.
    Во всяком случае при работе сервера с небольшим количеством клиентов ICS мне нравится больше, чем Indy.


    > kashey ©   (19.11.18 08:55) [11]
    >
    >
    > > то не нужно изобретать велосипед со сложной асинхронной
    > > логикой, а заюзать Indy.
    >
    > Попробуйте слушать сервером порт, подключить к нему несколько
    > клиентов, а затем в конце  корректно остановить сервер (те.
    >  после отключения всех клиентов установить для сервера Active
    > := False). Куча проблем на ровном месте из-за многопоточности
    >  

    Покажите ваш код. С Indy и я и многие другие работали и "кучи" проблем не видели.
  • Eraser © (24.11.18 05:02) [13]
    вот нашел старую ветку http://pda.delphimaster.net/?id=1454674277&n=4

    там DVM хорошую ссылку дал.
Есть новые Нет новых   [95456   +70][b:0.001][p:0.005]