Утеря данных при передаче через TCP/IP ?!

Здравствуйте !
Может я криво искал, но не могу нигде найти ответ на свой вопрос, а самому - уже за 2-е недели сломал голову. :huh:
Короче говоря, написал я асинхронный TCP/IP сервер, работает хорошо, быстро, нареканий небыло, пока не начал "жестко" тестить. Вот тут и вылезла страшная проблемма - при передаче пакетов размером в 32 байта более 50 раз в секунду ...
Я запускаю сервер и два клиента на одной машине, одного клиента включаю на прием, другого ставлю на передачу - сколько один передал, столь второй принял. Включаю обое в режим приемо-передачи - в среднем ( образно ): переданно 100% - принято 60 - 80%. Скорость посылки пакетов размером в 32 байта, составляет 50 раз в секунду ( 20 mSec ).
Я и не знаю, в чем проблемма - или мой сервер "глотает" пакеты, или клиенты не успевают принимать ... :'( Сервер написан по модели "порта завершения".
Тестил "чужой" сервер написанный по принципу "многопоточности" ( каждый новый клиент - новый поток ) - все пакеты доходят ! Сервер написанный на .NET платформе ( исходников нету ).

0

Какие такие "пакеты" в TCP ??? И откуда они взялись?

0

Извените - не корректно выразился !
Вместо "пакетов" - "текстовые сообщения", размером в 32 байта, зашифрованная команда для клиента. Пример команды - приводить не буду, т.к. это не столь важно. Сервер работает по протоколу TCP/IP, и должен обслуживать от 150 до 1000 клиентов. Сервер написан по принципу "ECHO SERVER", то есть - один передает, все слушают. Так вот выходит, что если посылки очень частые - кто-то "глотает" некоторые команды, только не могу понять кто - или сервер, или клиент.

0

Возвращаемые значения все проверяются? На сервере оно точно отправляется и не выдает ошибку? К клиенту точно ничего не приходит или приходит что-то не то?

0

"Возвращаемые значения все проверяются?" - вопрос не понял !
"На сервере оно точно отправляется и не выдает ошибку?" - стоит условие, что если WSASend < 0 - отключить все сокеты и вывалится с ошибкой ! - не вываливается !
"К клиенту точно ничего не приходит или приходит что-то не то?" - приходит к клиенту все то - но в гороздо меньшем количестве ! Команды четкие, без обрывков, и без дописей чето-то лишнего. Даже не знаю в чем проблемма ... :huh:

0

1. Сниффером проверял - что отправляют клиенты и что получает сервер?
2. Учитываешь ли ты возможную фрагментацию "текстовых сообщений" при последовательных вызовах WSARecv(), а также возможное изменение порядка следования принятых сообщений?

0

1. Сниффером не проверял, ни как не могу скачать.
2. Фрагментации нету, т.к. я проверяю внутри клинта на правильность комманды, если нет - тогда вывести ошибку. Ошибку не выводит. Возможность изменения порядка следования сообщений - не учитываю вообще никак. Я не представляю, как это можно проверять и контролировать - ведь сервер асинхронный ... :huh:

0

"Возвращаемые значения все проверяются?" - вопрос не понял !

Когда делаем WSARecv(), она возвращает значение, по которому мы точно можем сказать: отправилось сообщение, или возникли ошибки.

Можно поточнее узнать, что означает фраза "асинхронный сервер"? Неблокирующие сокеты?

0

1. http://www.download3k.com/Inst... ereal.html
2. Как проверяешь валидность сообщений? (можно привести упрощенный код)
2.1. Зависит ли что-нибудь в системе от порядка следования сообщений? Для систем, построенных с использованием IOCP, такое изменение происходит сплошь и рядом.

Vovan-VE: "асинхронный сервер" - использует IOCP (сообщение 10.06.2008, 21:49 ).

0

Сообщение от Vovan-VE Когда делаем WSARecv(), она возвращает значение, по которому мы точно можем сказать: отправилось сообщение, или возникли ошибки.

- а ... на счет этого - конечно проверяю - все принимается успешно.

Сообщение от Vovan-VE Можно поточнее узнать, что означает фраза "асинхронный сервер"? Неблокирующие сокеты?

- Модель "Порты завершения".
Поставил снифер ... и был в шоке - сервер принимате абсолютно все сообщения от клиентов - а вот сервер выдает ... полный бред.
Короче - теория теста такова:
1. Запускаем сервер ( принимает от одного клиента, передает всем - кроме того, кто послал )
2. Запускаем клиента №1 и №2
3. Включаем клиента №1 на передачу - ждем некоторое время
4. Включаем клиента №2 на передачу - ждем некоторое время
5. Выключаем клиента №1
6. Выключаем клиента №2 ( Он должен был принять все сообщения от Клиента №1 )
7. Сравниваю количество посылок: Клиент №1 передал 850 посылок - Сервер передал клиенту №2 - 812 посылок, Клиент №2 принял - 812 посылок. :huh:
8. Далее не проверяю - не вижу смысла ! :'(
9. Ни одно исключение внутри сервера не отработало ! :huh:

0

Нет, что-то у тебя не так.... Куда делись еще 38 посылок? Далее без конкретного кода обсуждать бесполезно - телепаты все ушли в отпуск на все лето, так что умозрительно догадаться, что именно у тебя неправильно, мы вряд ли сможем...
Например, как твой сервер отработает такой реальный use case: клиент последовательными вызовами WSASend() записывает в сокет посылки (например, байты): "11111", "22222", "33333", "44444", "55555", а сервер последовательными же вызовами WSARecv() получает: "11111", "2222244", "4", "4433333", "55555" ? Правильный сервер должен правильно принять их, а если порядок обработки посылок важен - то и обработать их именно в том порядке, как клиент посылал их (т.е. начиная от "11111" и заканчивая "55555").

0

Сообщение от CheshireCat Правильный сервер должен правильно принять их, а если порядок обработки посылок важен - то и обработать их именно в том порядке, как клиент посылал их (т.е. начиная от "11111" и заканчивая "55555").

- все бы хорошо, но как это сделать, я же написал асинхронный сервер ... :huh:

Вложения

TCPAsynServer.rar (4.5 Кб, 59 просмотров)

0

1. Да без разницы, синхронный он или асинхронный....
2. В приведенном коде ясно, как считается количество переданных сообщений. Но не ясно, как ты считаешь количество принятых сервером сообщений. Откуда вывод о количестве принятых сервером сообщений (12.06.2008, 22:40 п.7)?

0

Раньше в области case OverComplete::action_recv: было условие:
if ( dwRecvOfByte > 0 ) recv_counter++;, затем я его убрал, т.к. сумма сообщений принятых от 2-х пользователей = значению переменной recv_counter. Я посчитал, что оно тут больше не надо, т.к. и так видно, что он все читатет !

0

Ну, в общем, я примерно такого ответа и ожидал...
Вот use case, который твой сервер отработает неправильно:
Клиент 1 передает (в строках 274-282) серверу сообщения: 11111, 22222, 33333, 44444 - итого счетчик U1 честно покажет 4 сообщения. Сервер принимает (в строках 284-294) сообщения: 11111, 2222233333, 44444 - итого три "сообщения". Ах! Одно сообщение потеряно.... Вот тебе и расхождение числа переданных и принятых сообщений, описанное 12.06.2008. Хотя TCP/IP абсолютно честно передал на приемный конец все байты, которые в него запихали на передающем конце.

По-моему, ты совершаешь весьма типичную ошибку. Чтобы правильно интерпретировать, что происходит, думай о TCP/IP соединении как о "потоке" (или "ленте") байтов - ты же сам указал флаг SOCK_STREAM, не так ли? Функция WSASend() просто пишет байты в этот поток. Функция WSARecv() просто "вынимает" из потока сколько-то байтов, - а именно, столько, сколько доступно в момент ее вызова во внутреннем буфере драйвера tcpip.sys. Эти байты не обязаны вообще образовывать какое-либо сообщение, - за анализ семантики полученных байтов отвечает ПО верхнего уровня (пользователя).

0

:fool: - этож надо было так затупить !
Поставил всевозможные проверки - стало работать значительно лучше, "еще есть потери", и я знаю где они, но ... :'(
У меня тогда еще вопрос: почему в приемном буфере изредка, получается (стр. 284-294) после основной команды, какие-то обрывки команд и длина этих "обрывков" порой доходит до сотен байт ? :huh: Откуда они берутся, и что самое интересное, что dwRecvOfByte показывает длину с "обрывками" ...
С этим я пока, что не придумал как боротся ... :huh:

0

Что означает "основная команда" и что означает "обрывки команд"?? Ничего пока не понял....... это, видимо, относится к семантике передаваемых байтов, а эта семантика пока нигде четко не описана...

0

Ну одна, из моих комманд выглядит так: 0,0,45,68,5,30,48,0,110;, а в приемном буфере я вижу ( фрагмент - все, что начинается с [\] - это коды неотображаемых символов, которые находятся в буфере ): 0,0,45,68,5,30,48,0,110;[\0][\8]4,1,[\0];[\0];;[\9];[\0],0,-1;5,2;[\0][\9]4,1,0,2; ну и так 96 байт !

0

Это шибко смахивает на то, что ты передаешь или принимаешь не только собственно команду, но впридачу еще и весь "мусор", который находится в буфере за последним байтом команды, - размер буфера наверняка превышает размер команды, не так ли? Ищи и проверяй, где и сколько байт ты пишешь в сокет и читаешь из него.

Добавлено через 41 минуту
И вот это еще мне очень понравилось (раньше почему-то не обратил внимания сразу):Это как??? Ты инициировал отложенную операцию записи (WSASend() наверняка вернула WSA_IO_PENDING - кстати, надо проверять код возврата!) и тут же освобождаешь буфер с данными передачи, - т.е. разрешаешь исполняющей системе заново использовать для своих внутренних таинственных нужд тот кусок памяти, где лежат те самые данные, которые ты хочешь передать? Лихо.... И что ты получишь теперь на приемном конце, как ты думаешь? Освобождать буфер можно только в тот момент, когда операция записи полностью завершена.

Вот еще пара придирок :Ты понимашь разницу между целочисленным 0 и указателем NULL ? Стандарт гарантирует правильное преобразование 0 в NULL, но нигде, насколько я знаю, не гарантирует преобразования NULL в 0.

0

:fool: - затупил я с удалением данных, нельзя этого было далять. Я после отправки исходника через некоторое время уже убрал этот бред, он там лишний. А поставил уделение - если комманда успешно отравленна.
Просто всречал такие записи - вот решил и себе применить. Хотя правильней было-бы написать = 0.

На счет мусора: буфер для передачи - размером в длину команды, а вот приемный буфер - действительно очень большой, 1024 байта. Наверное приемный буфер нужно сделать - размером в самую длиную команду ...

0