Мастера DELPHI, Delphi programming community Рейтинг@Mail.ru Титульная страница Поиск, карта сайта Написать письмо 
| Новости |
Новости сайта
Поиск |
Поиск по лучшим сайтам о Delphi
FAQ |
Огромная база часто задаваемых вопросов и, конечно же, ответы к ним ;)
Статьи |
Подборка статей на самые разные темы. Все о DELPHI
Книги |
Новинки книжного рынка
Новости VCL
Обзор свежих компонент со всего мира, по-русски!
|
| Форумы
Здесь вы можете задать свой вопрос и наверняка получите ответ
| ЧАТ |
Место для общения :)
Орешник |
Коллекция курьезных вопросов из форумов
KOL и MCK |
KOL и MCK - Компактные программы на Delphi
Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / rsdn.org

 
Чтобы не потерять эту дискуссию, сделайте закладку « предыдущая ветвь | форум | следующая ветвь »

ics twsocket


kashey ©   (15.11.18 16:30

Подскажите пожалуйста, кто работал с этой библиотекой, как правильно читать данные?
Данные которые приходят, имеют такой формат:
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://www.delphimaster.ru/cgi-bin/forum.pl?id=1454674277&n=4

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


версия для печати

Написать ответ

Ваше имя (регистрация  E-mail 







Разрешается использование тегов форматирования текста:
<b>жирный</b> <i>наклонный</i> <u>подчеркнутый</u>,
а для выделения текста программ, используйте <code> ... </code>
и не забывайте закрывать теги! </b></i></u></code> :)


Наверх

  Рейтинг@Mail.ru     Титульная страница Поиск, карта сайта Написать письмо