2010-06-30 1 views
1

У меня есть интерфейс сокетов tcpip для стороннего программного приложения. Я реализовал этот интерфейс для нескольких клиентских сайтов без проблем. Последний клиент, хотя ... проблемы. Мы включили регистрацию в приложениях с обоих концов, а также установили Wireshark на ПК для регистрации необработанного трафика tcpip. При этом мы доказали, что мое серверное приложение успешно отправляет сообщение, компьютер получает сообщение, но клиентское приложение его не видит. (Это проблема полностью прерывистая, поэтому проблема заключается в устранении неполадок.)Задержка перед отправкой сообщения через сокет - как это помогает?

Детали сокета такие же простые, как и у них: один сокет обрабатывает двустороннюю связь между сервером и ПК. Сообщения представляют собой простой текст ascii и довольно короткий (а не XML). Сервер инициирует обмен сообщениями, отправив первое сообщение, а затем клиент отвечает несколькими сообщениями. Сокет постоянно открыт, пока приложения запущены. Клиентское приложение сконструировано таким образом, что конечный пользователь может обрабатывать только один случай за раз, что предотвращает возникновение конфликтов сообщений. У них есть какой-то опрос, их приложение «спящий режим», пока не увидит инициирующее сообщение с сервера.

Сторонний поставщик посоветовал мне добавить несколько секунд задержки, прежде чем отправить их инициирующее сообщение. Я не вижу, как это помогает. Если клиент «спящий», просто опрос сокета, ожидающего сообщения, как добавить задержку до первого сообщения? Это не то, что мы отправляем два сообщения, а второй теряем. Он теряет первое сообщение. Поэтому я не вижу, как это важно, если мы отправим это сообщение сейчас или через две секунды.

Я спросил их, и они не дали мне подробностей. В их кодировании могут быть некоторые проприетарные детали, которые они не хотят раскрывать мне, и это справедливо. Поэтому я спрашиваю здесь, потому что я всегда изучаю новые вещи о программировании сокетов. Может быть, вы, ребята, можете пролить свет на то, как на опрос tcpip-сокета могут влиять сроки передачи сообщений?

ответ

2

С его чужого клиента, и они не скажут вам, что он делает (кроме как сказать «вставить задержку»), ответ, вероятно, заключается в том, что их клиент читает и отбрасывает сообщение, потому что его еще не в состоянии чтобы справиться с этим. Задержка позволит клиентскому времени войти в состояние, в котором он может правильно ответить на сообщение.

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

Непродолжительный трафик (1) на клиенте, чтобы узнать, какие системные вызовы он делает, его трудно сказать, что делает клиент на самом деле.

+0

Поскольку это проблема синхронизации, когда задержки помогают клиенту читать лучше, другая возможность заключается в том, что клиент может не просто правильно читать. Он может считывать больше байтов за один раз, тогда он действительно знает, как обращаться, не принимая во внимание, что индивидуальное чтение может (и обычно) возвращать байты, которые могут принадлежать более чем одному сообщению, и что клиент отвечает за обнаружение и буферизацию данных сокета, чтобы он мог правильно определять границы между сообщениями. Многие программисты-новички-сокеты предполагают, что 1 write = 1 read, и это просто не так. –

+0

Если у них есть условие гонки, не было бы лучшего предложения отправить мое сообщение дважды? В конце концов, что должно предотвратить состояние гонки через две секунды после завершения моей задержки? –