Подскажите пожалуйста, кто работал с этой библиотекой, как правильно читать данные?
Данные которые приходят, имеют такой формат:
5#0Hello#0, т.е. в начале число байт #0 строка этой длинны #0

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




Читал еше просто через ReceiveStr. Всегда получаю только кусок текста с конца, по размерам примерно половину от всего что нужно получить, начальная часть теряется. Подскажите почему так?

Потому что протокол передачи данных у тебя такой. TWSocket не причем

Какой протокол, я не знаю (реализация клиента не моя). Но в инди IdTCPserver я читал очень просто: Ch := AContext.Connection.IOHandler.ReadChar() пока Ch <> #0

> очень просто: 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;

Слава Богу пришлось бросить Indy, а то я думал с ума сойду с ее много поточной системой. Единственный плюс - примерно понял как оно работает. В ics все и всегда в основном потоке? Тогда и таймерочками побаловаться неверное можно для ожидания данных?

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

Не всё и не всегда. Но в потроха ICS вам пока рано лазить.

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

А вот это уже не ics. ICS работает по событиям.

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

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

все остальное не имеет право на жизнь в новых проектах, только legacy.

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

Лёша, ты можешь подкрепить твою нелюбовь к библиотеке ICS реальными данными?

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

конечно, испытывал ее в свое время. она годится разве что какой-нибудь клиент написать. для серверов с несколькими тысячами соединений она не годится, а на десятках тысяч даже испытывать не стал. если нужен сервер на 1000-2000 соединений, то не нужно изобретать велосипед со сложной асинхронной логикой, а заюзать Indy.

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

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


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

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

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

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

> 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 и я и многие другие работали и "кучи" проблем не видели.

вот нашел старую ветку http://pda.delphimaster.net/?id=1454674277&n=4

там DVM хорошую ссылку дал.