UDP
Есть программа — сервер, которая слушает порт.
Есть клиент, который кидает пакеты на тот порт, и получает с того порта.
В клиенте 2 нити:
одна слушает свой порт(исп. select)
одна рабочая
Я через рабочую нить откидываю 3 сообщения на сервер.(сокеты созданы по-умолчанию — в блокированном режиме), но на сервер почему-то доходят иногда все, иногда 2-е, иногда 3-е сообщение. Что это может быть?
з.ы. если же я поставлю Sleep(100) в рабочей нити после каждого send'a, то все доходит.
з.ы. Windows XP sp2, VS7.1, LAN
Здравствуйте, Agile, Вы писали:
A>UDP A>...Что это может быть?
UDP и есть.
Re: Сообщения не доходят
От:
Аноним
Дата:
13.03.05 11:16
Оценка:
Здравствуйте, Agile, Вы писали:
A>Я через рабочую нить откидываю 3 сообщения на сервер.(сокеты созданы по-умолчанию — в блокированном режиме), но на сервер почему-то доходят иногда все, иногда 2-е, иногда 3-е сообщение. Что это может быть?
A>з.ы. если же я поставлю Sleep(100) в рабочей нити после каждого send'a, то все доходит. A>з.ы. Windows XP sp2, VS7.1, LAN
Вероятно, вы считаете(нумеруете) сообщения таким образом, что каждый вызов функции send(...) для клиента соответствует одному исполнению функции recv(...) для сервера, т.е. когда из вашей основной нити программы идет отправка сообщений подряд... На сервер они приходят в один буфер, и читаются из него поточно(независемо от количества send-ов), т.е. образом, вы отсылаете не "сообщения", а части(пакеты) одного непрерывного потока. Для испраления такого рода ошибки обычно используют 3 подхода:
1. сообщения имеют строго определнный размер, а recv(...), соответсвенно, принимает указанное количество байт(записей);
2. вводится спциальный символ-разделитель, при чтении которого из буфера, происходит разделение на сообщения;
3. при отправке/приеме в/из буфер/а сперва пишется/читается количество байт(записей) необходимое для одного сообщения.
wrote:
> Вероятно, вы считаете(нумеруете) сообщения таким образом, что каждый вызов функции send(...) для клиента соответствует одному исполнению функции recv(...) для сервера, т.е. когда из вашей основной нити программы идет отправка сообщений подряд... На сервер они приходят в один буфер, и читаются из него поточно(независемо от количества send-ов), т.е. образом, вы отсылаете не "сообщения", а части(пакеты) одного непрерывного потока.
Agile wrote:
> Здравствуйте, Michael Chelnokov, Вы писали: > > MC>Здравствуйте, Agile, Вы писали: > > A>>UDP > A>>...Что это может быть? > > MC>UDP и есть. > > да но клиент и сервер запускаются на одной машине. Т.е. происходит loopback при отправке и при этом такие потери ?
Если клиент занят только посылкой максимального количества дейтаграмм, то возможно, что буфер сервера переполняется и дейтаграммы отбрасываются.
Еще возможно, что твой клиент стартует раньше сервера и посылает дейтаграммы на еще не прослушиваемый порт.
Здравствуйте, MaximE, Вы писали:
ME>Это для TCP. Автор треда спрашивал про UDP.
Хорошо, что поправили, но я же сказал вероятно... И вообще, как сказал сам автор во 2-ом посте, он запускает приложения на одной машине, так что проблем с передачей самих данных быть не должно, а, соответсвенно, и ошибок в этой самой передаче. А в вашем посте, я, извините, не увидел совета
Здравствуйте, Agile, Вы писали:
A>>>...Что это может быть?
MC>>UDP и есть.
A>да но клиент и сервер запускаются на одной машине. Т.е. происходит loopback при отправке и при этом такие потери ?
UDP == Unreliable Datagram Protocol. т.е. по своему определению он ничего не гарантирует. ни доставки, ни порядка прибытия датаграмм, ни по сети, ни в пределах одной машины... в таких случаях говорят "контроль целостности/итп должен быть возложен на протокол более высокого уровня". Sleep в данном случае играет роль бубна
Re[5]: Сообщения не доходят
От:
Аноним
Дата:
13.03.05 22:10
Оценка:
Здравствуйте, MaximE, Вы писали:
ME>wrote:
>> ME>Это для TCP. Автор треда спрашивал про UDP. >> >> А почему вы думаете что это не для TCP?
ME>Что "это"? И причем здесь "не"?
Да, я как-то не правильно сказал.
Я имею в виду, что если отправка/получение реализованно с помощью функций recv/send, то пакты дейисвительно могли смешаться.
Здравствуйте, Agile, Вы писали:
A>>>UDP A>да но клиент и сервер запускаются на одной машине. Т.е. происходит loopback при отправке и при этом такие потери ?
Это не потери. Скорее всего, как тут уже было отмечено, происходит переполнение буфера на принимающей стороне (новые сообщения затирают старые). Тем более это возможно на одной машине, т.к. пока процессор занят отправляющим потоком, принимать просто некому — буфер успевает переполнится быстрее чем осуществляется переключение процессора на принимающий поток.
Эволюционное решение — увеличить размер буфера.
Революционное — пересмотреть согласование работы клиента и сервера. В особенности обратить внимание на сервер, чтобы он в любом случае успевал выгребать сообщения из буфера быстрее чем они туда могут поступать. Ну а в случае когда и клиент и сервер находятся на одной машине, учитывать тот факт что они работают последовательно (я так понимаю, машина не двухпроцессорная) и исходя из этого анализировать ситуацию.
