Здравствуйте, Ifrin, Вы писали:

I>Ну досылку делать надо это да, у меня скорее вопрос заключается немного в другом.
I>Например система вида: "сервер постоянно шлет пакеты-> клиент постоянно считывает, каким-то образом определяет недошедшие и отправляет сообщение серверу о потерях-> сервер вместе с обычными пакетами шлет недошедшие". То есть сервер находиться в постоянной пересылке, он не ожидает ответа об отдельных блоках пакетов от клиента. Тогда взглянем на следующую ситуацию: сервер отправляет пакеты, неожиданно появился сбой и 1000 были уничтожены, он отправил 1001 пакет и продолжает передачу дальше, не зная что предыдущие не дошли до клиента, клиент принял 1001 пакет и заметил, что не хватает 1000 пакетов. Дальше единственный выход, это сказать серверу что бы тот остановился(за это время сервером может быть отправлено еще 100 пакетов) и начать передавать ему информацию о потерянных пакетах, что тоже довольно проблематично, т.к. некоторые из них могут опять потеряться)

Нет, это плохо. Вы можете начать посылать пакеты быстрее, чем они в сеть пролазят. Надо обязательно делать congestion control. Т.е., сервер может послать N пакетов, но пока он не получил от клиента подтверждение о том, что сколько-то из них дошло до клиента, он должен притормозить и ждать. Выражаясь чуть точнее, сервер должен стремиться поддерживать такое состояние, когда не более, чем N пакетов болтаются "в воздухе", т.е. он их послал, но еще не знает, дошли они, или нет. Чему равно N — тоже хороший вопрос, в TCP этот параметр меняется динамически по довольно нетривиальному алгоритму. N должно быть достаточно велико, чтобы сервер не останавливался из-за большого round-trip-time, но не настолько большим, чтобы заливать роутеры по дороге.

Пакеты могут приходить не в том порядке, в котором они были отправлены. Правда, это в реальных интернетах бывает не так уж и часто, тоже где-то в районе 1%. Это желательно учитывать. Т.е., если клиент получил 11-й пакет, не получив 10-го, прежде, чем требовать ретрансмита, есть смысл немного подождать, вдруг 10-й пакет просто заскочил по дороге пропустить рюмашечку и придет чуть позже.

Перепосылку лучше делать селективную. Т.е., если не дошел пакет с номером 10, а сервер уже послал 20 пакетов, лучше бы перепослать только 10-й, а не все с 10-го по 20-й.

Ну и наконец, надо не забывать, что ответы клиента тоже могут теряться. Алгоритм должен уметь восстанавливаться из такой ситуации, а не ждать потерянного ответа до морковкина заговения.

I>Собственно вопрос в том, стоит ли пытаться сделать что-нибудь на основе подобной системы или же лучше остановиться на стандартной.

Pzz>>Почему? TCP лучше во многих отношениях. Например, есть полно контор, где UDP траффик закрыт наружу вообще, и ничего вы по UDP в/из такой конторы не передадите.
I>Да я понимаю что лучше, просто надо именно UDP.

Ну приоткройте всеж завесы тайны, откуда такое требование?