2011-03-20 1 views
0

Я реализовал связь TCP/IP между программами VB и VC++, запущенными на одном компьютере. На стороне VC++ я создаю поток, который прослушивает подключения. На стороне VB я использую Winsock API для подключения к серверу C++. Кажется, что все работает нормально, особенно когда я вручную отлаживаю и перебираю сообщение. Протокол основан на тексте, команды заканчиваются на '\ n' и могут иметь или не иметь ответа.Как сериализовать telnet как связь при подключении двунаправленного сокета?

И вот в чем проблема. Я пытаюсь реализовать команды, которые отправляются на сервер, для этого требуется некоторая обработка, и сервер отправляет их обратно клиенту. В простых условиях это работает нормально, но при большой нагрузке или в разных машинных конфигурациях иногда связь прерывается.

Клиент может отправлять команду, но сервер может отправлять ответ предыдущей команды. Клиент VB каким-то образом получает фрагментированный ответ (скажем, вместо «DATA RECEIVED» он получает «EIVED»), который разбивает конечный автомат, который я использовал для отслеживания соединения.

Так что, клиент и сервер говорят одновременно, и это создает проблему. Как я могу сериализовать или поставить в очередь эту связь? Я понимаю, что это будет похоже на проблему столкновения сетевых пакетов в сети Ethernet.

+5

TCP уже сериализован - у вас есть ошибка в коде. – Erik

+0

Чаще всего ошибка в коде. Не компилятор, операционная система или стандартная библиотека шаблонов. –

+0

Да, если бы я не сделал ошибку в своем коде, я бы не стал просить здесь о помощи по проблеме, которую я едва понимаю. Любые предложения о том, что я могу сделать, чтобы узнать, где эта ошибка? Серверная сторона? Сторона клиента? Есть ли способ удостовериться, что хотя бы одна из конечных точек делает все правильно? Может быть, прокси для регистрации/мониторинга связи? Какие инструменты можно отладить, кроме printfs? –

ответ

5

Вместо того, чтобы столкнуться с пакетами, я предполагаю, что вы читаете больше, чем вы ожидаете от сокета. Может быть, что ваше последнее чтение из сокета выглядит примерно

OTHER STUFF\nDATA REC 

и на следующем читать вы получите «EIVED»?

+0

Возможно. VB действительно базовый, поэтому он отображает только последнее полученное сообщение в графическом интерфейсе. Мне нужно записать все в файл и посмотреть, не проблема в том, что два ответа попадают в очередь и доставляются в одном и том же сокете. Из других ответов видно, что TCP сериализуется, поэтому это кажется единственным возможным объяснением. Есть ли эквивалент TCP fflush(), который может помочь мне здесь? –

+1

TCP - это протокол потока. Представьте, что вы читаете файл, к которому добавляется еще один процесс. Вы можете читать только с того места, где вы сейчас находитесь, и только то, что до сих пор было зафиксировано на диске. Нет «сообщений», кроме того, что ваши две программы определили между собой, поэтому вам нужно деблокировать поток в сообщениях на основе какого-то взаимного соглашения (символ EOR, префикс длины и т. Д.). Каждый вызов .GetData после DataArrival гарантирует только один байт данных, но может возвращать 1, 3 или 17 и половину ваших «сообщений». – Bob77

+0

Рассматривая код и прочитав ваши ответы и руководство по адресу http://code.google.com/p/cocoaasyncsocket/wiki/CommonPitfalls, я вижу, что проблема заключается в клиенте VB, который не ожидает усеченного сообщения, и сохраняет данные после \ n при приеме. –