Доброго времени!
На компе 2 проги у меня должны общаться с помощью сокетов.
На одной стороне - синхронный неблокирующий сокет.


Здесь приведен чуть сокращенный код, который хотелось бы ускорить. Обмен командами 5 - 15 переменных, объем буфера 20 - 60 байт.
Как можно ускорить обмен?

До какой скорости? Первое что вижу - пересмотреть протокол обмена и не дергать сокет почем зря на каждый чих, но и в этом варианте как есть, существенных тормозов по идее быть не должно (с клиенской стороны)

<OFFTOP>
Может я ещё раз "ступлю", но я не понимаю как "скорость работы сокета" может зависеть от синхронности/асинхронности? Или от "блокирующего/неблокирующего" режима его работы.
Имхо, это из той же самой оперы, что и мнения/убеждения о том, что доппотоки ускоряют работу любой программы.
</OFFTOP>

>
> Евгений07 ©   (25.09.16 20:41) 

по этому куску странного кода ответить на вопрос нельзя.

> Rouse_ ©   (25.09.16 23:11) [1]
Схема работы:
1. Клиент может прерываться на отправление серверу информации (очень неравномерно).
2. ДЛЛ на стороне клиента с этой оказией может проверить сокет сервера на наличие управляющей команды (очень не часто, но важно).
> Германн ©   (26.09.16 00:58) [2]

Если бы я мог и на клиенте сделать асинхронный сокет, обрабатывающий
информацию сразу, то проблема бы похудела.
А так получается я должен при каждой записи в сокет проверять его на чтение. А команд может быть несколько.

На глаз в эмуляторе клиента задержка приема - передачи заметна.

Нет ли технической возможности ускорить работу приведенного кода?
Особенно на чтение?

> Схема работы: 1. 2.

Ууу - у меня в голове случилось КЗ, буду удлинять...


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


Так сделай, в чём вопрос?
( тока это, "асинхронный" априори ни разу не "сразу" )) )


> А так получается я должен при каждой записи в сокет проверять его на чтение.


А кому должен то, и в валюте или в рублях?


> Нет ли технической возможности ускорить работу приведенного кода?
> Особенно на чтение?


"приведенного" нет, даже если добавить ещё два "Len := SelectFDSet", а в Timeout.tv_usec записать 1 в надежде, что твой "SelectFDSet" будет выполнен за 1/1000000 секунды.

зы.
Спокойно читаем теорию, смотрим примеры, пишем свой простой клиент/сервер
(чтобы была точка отсчёта, что оно таки работало),
а уж потом криптуем сферический вакуум во всякие ReadBuf(213 ...

>  Евгений07 ©   (26.09.16 08:36) [4]
>
> > Германн ©   (26.09.16 00:58) [2]
>
> Если бы я мог и на клиенте сделать асинхронный сокет

А почему не можешь?

> На одной стороне - синхронный неблокирующий сокет.

RTFM. Такого не существует.


> Может я ещё раз "ступлю", но я не понимаю как "скорость
> работы сокета" может зависеть от синхронности/асинхронности?
>  Или от "блокирующего/неблокирующего" режима его работы.
>
> Имхо, это из той же самой оперы, что и мнения/убеждения
> о том, что доппотоки ускоряют работу любой программы.

Может и зависеть к примеру сделает автор блокирующей сокет  у него скорость и поднимется.  А по поводу, доп потоков.   Недавно мерил sleep(1) в основном и и в доп потоке. Оказалось, что задержки разные, в доп потоках быстрее!


> На глаз в эмуляторе клиента задержка приема - передачи заметна.

Сделайте простой тест без вашей дллки. Скорость передачи на одном компьютере несколько миллионов байт- ваши команды могут обрабатываться до 1 миллиона штук. И на глаз команды никак не могут быть заметны. Даже если передавать по сети, задержки незаметны, так как типично составляют 40-60 мс, что меньшее порога 100 мс - порога заметности.

Скорее всего проблема в вашей длл которая долго думает. Случаем это не СУБД?