нужно разьяснение по работе с сервером OpenOCD , используя команды write/read

кто может подсказать по связке server-client (telnet) OpenOCD.
Почему необходимо делать исскуственную задержку между операциями write-read с стороны клиента. Без "задержки" (экспериментально подобрана величина 50мс) не могу получить эхо ранее отосланной команды серверу и данные от его.

Все возможные способы опросить сервер на предмет полной готовности к отправке данных не дал НИКАКОГО результата.

Все это работает прекрасно если шагать по программе в ручном режиме (программа на С из под Линукса). Уже мозг закипает ((

0

логично: Вы отправили серверу сообщение, он должен его принять и обработать прежде чем дать ответ, а на это требуется какое никакое время. Также логично то, что нет никакого смысла теребить сервер на тему готов он ответить или нет, он ответит когда будет готов. Смотрите в сторону блокирущих сокетов которые будут висеть на recv или recvFrom пока не придет ответ или bytesAvailiable для асинхронного режима.

0

Механизм понятен в принципе , но из-за отсутствие опыта с сетевым программирование да еще и на С , где все надо прописывать своими ручками, сформировался этот вопросю. Я пробовал использовать recv() вместо read(), менял время в параметре, но устойчивое чтение от сервера так и не получилось - все работало нестабильно и с потерей данных (эхо отосланных команд и полезных данных от сервера). Все это работает на одном компьютере - никаких проводов и WiFi соединений нет.
Я пробовал использовать select() для опроса сервера перед чтением - тоже непонятные глюки. В результате решил попробовать более навороченную poll() и результат совпал с ожиданием! Теперь эта команда стоящая перед задежкой и сразу после - дает четкое представление о состоянии сервера перед считывание своими флагами в структуре и возвращаемым значением!
Осталось все это правильно задействовать в программе и удалить задержки.
Кстати на более осмысленное понимание процессов общения сервера-клиента дала вот эта фраза:
"у сетевых сокетов есть и недостатки. Даже если сокеты используются для обмена данными на одной и той же машине, передаваемые данные должны пройти все уровни сетевого стека, что отрицательно сказывается на быстродействии и нагрузке на систему".
Ну и выясние места "затыка" в моем алгоритме тоже сыграло немаловажную роль.
До этого я исходил, что процессы чтения-записи между сервером и клиентом идут мгновенно (ввиду мощного процессора и работы на одном компьютере). Но реальность оказалось иной - сетевой обмен всегда неспешен и требует "ухода" и постоянной "заботы" о нем))) когда это все рулиться программой на С.

0