Клиент шлет серверу большой UDP-пакет — около 10000 байт.
Если напринимающей стороне пакет не собирается полностью, что получит читатель ?
Или не получит вообще ничего ?
Сам протокол, построенный на UDP, простой.
Клиент серверу шлет пинг и ждет ответа
Сервер отвечает на пинг
По получении ответа на пинг клиент шлет запрос о получении данных.
Сервер отсылает данные, затребованные клиентом.
Нужно ли вводить дополнительные данные в пакет (размер, контрольная сумма), на тот случай, если пакет придет неполным(фрагмент потерялся) ? или таковой ситуации не будет ?
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
O>Клиент шлет серверу большой UDP-пакет — около 10000 байт.
Я "сильно неуверен", что клиенту это удастся:
MSDN: send() The send function is used to write outgoing data on a connected socket. For message-oriented sockets, care must be taken not to exceed the maximum packet size of the underlying provider, which can be obtained by using getsockopt to retrieve the value of socket option SO_MAX_MSG_SIZE. If the data is too long to pass atomically through the underlying protocol, the error WSAEMSGSIZE is returned, and no data is transmitted.
Где-то фигурировала цифра 1440 байт, но точных источников не скажу.
Здравствуйте, NavuhodonosoR, Вы писали:
O>>Клиент шлет серверу большой UDP-пакет — около 10000 байт. NR>Я "сильно неуверен", что клиенту это удастся: NR>
MSDN: send() The send function is used to write outgoing data on a connected socket. For message-oriented sockets, care must be taken not to exceed the maximum packet size of the underlying provider, which can be obtained by using getsockopt to retrieve the value of socket option SO_MAX_MSG_SIZE. If the data is too long to pass atomically through the underlying protocol, the error WSAEMSGSIZE is returned, and no data is transmitted.
NR>Где-то фигурировала цифра 1440 байт, но точных источников не скажу.
Вообще сам UDP позволяет отправить до 65К данных. У меня в локальной сети все работает.
Только проверить потери не могу
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
O>Привет !
O>Клиент шлет серверу большой UDP-пакет — около 10000 байт.
не пакет а _блок_данных_ — разве у тебя есть средства для того чтобы программно рулить всеми параметрами UDP?
O>Если напринимающей стороне пакет не собирается полностью, что получит читатель ? O>Или не получит вообще ничего ?
read у клиента будет читать все долетевшие до него UDP пакетики подряд
при этом нет НИКАКОЙ ганантии что долетят все или что долетит то что было отправлено
[ ... ]
O>Нужно ли вводить дополнительные данные в пакет (размер, контрольная сумма), на тот случай, если пакет придет неполным(фрагмент потерялся) ?
безусловно да
O> ... или таковой ситуации не будет ?
в незагруженной локалке такая ситуация маловероятна — в любом другом случае — весьма и весьма.
Удачи
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
O>Привет !
O>Клиент шлет серверу большой UDP-пакет — около 10000 байт. O>Если напринимающей стороне пакет не собирается полностью, что получит читатель ? O>Или не получит вообще ничего ?
Скорее всего не получит его вообще, т.к. это уровень на много ниже, чем читатель пакетов
К сожаления IP работает так, что если пакет не может собраться из франгментов, то требуется
повторение всего пакета заново, никто отдельных фрагмент повторить не может.
O>Сам протокол, построенный на UDP, простой. O>Клиент серверу шлет пинг и ждет ответа O>Сервер отвечает на пинг O>По получении ответа на пинг клиент шлет запрос о получении данных. O>Сервер отсылает данные, затребованные клиентом.
O> O>Нужно ли вводить дополнительные данные в пакет (размер, контрольная сумма), на тот случай, если пакет придет неполным(фрагмент потерялся) ? или таковой ситуации не будет ?
UDP кроме того, что на уровне IP проверяется контрольная сумма заголовка еще проверяет контрольную сумму UDP заголовка и данных
Я думаю, что проверять еще и самому контрольную сумму будет излишне.
O>Заранее благодарен
Здравствуйте, J.J.OK, Вы писали:
JJO>не пакет а _блок_данных_ — разве у тебя есть средства для того чтобы программно рулить всеми параметрами UDP?
Ну да. Блок данных.
O>>Если напринимающей стороне пакет не собирается полностью, что получит читатель ? O>>Или не получит вообще ничего ?
JJO>read у клиента будет читать все долетевшие до него UDP пакетики подряд JJO>при этом нет НИКАКОЙ ганантии что долетят все или что долетит то что было отправлено
Меня интересует, что получит читатель. Если из десятка фрагментов дойдет один, что вернет recvfrom ?
Здравствуйте, NavuhodonosoR, Вы писали:
NR>Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
NR>Где-то фигурировала цифра 1440 байт, но точных источников не скажу.
Если быть точнее, то это число 1492 (октета) и это только для Ethernet, в других сетях это число может быть другим.
Кроме того, шлюзы обязаны обрабатывать дейтаграммы до 576 октетов.
NR>Остальное поскипано
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
O>Вообще сам UDP позволяет отправить до 65К данных. У меня в локальной сети все работает.
Твои 65K данных(учти что это включая все заголовки) никакого отношения к локальной сети не имеют.
Если локальная сеть у тебя Ethernet, то пакеты побьются грубо по 1500 байт.
O>Только проверить потери не могу
Если ты работаешь через DirectPlay, то с ним идет шейпер dp8simui.exe, с помощью него ты может "замедлить сеть", т.е. он будет херить пакеты. Если ты работаешь напрямую с сокетами, то я не уверен, что директовский шейпер сработает, надо проверять.
Здравствуйте, Сергей Зизев, Вы писали:
СЗ>Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
O>>Привет !
O>>Клиент шлет серверу большой UDP-пакет — около 10000 байт. O>>Если напринимающей стороне пакет не собирается полностью, что получит читатель ? O>>Или не получит вообще ничего ? СЗ>Скорее всего не получит его вообще, т.к. это уровень на много ниже, чем читатель пакетов СЗ>К сожаления IP работает так, что если пакет не может собраться из франгментов, то требуется СЗ>повторение всего пакета заново, никто отдельных фрагмент повторить не может.
! Уважаемый, вы не тОчны — поясню:
есть _блок_данных_ пользователя
есть IP-пакет(ы)
есть MTU — Maximum Transfer Unit — определяемый физическим уровнем
так вот, если данные пользователя превышают MTU то IP побъет _блок_данных_ на несколько пакетов и гарантирует целостность заголовков IP-пакетов — определяющих адреса и проч.
Однако! IP НЕ гарантирует целостность данных!
Точно также как UDP не дает средств убедиться в том что дошли все пакеты.
Больше того, поскольку UDP это conectionless протокол, то и порядок доставки пакетов — тоже не гарантирован!
Здравствуйте, J.J.OK, Вы писали:
O>>>Клиент шлет серверу большой UDP-пакет — около 10000 байт. O>>>Если напринимающей стороне пакет не собирается полностью, что получит читатель ? O>>>Или не получит вообще ничего ? СЗ>>Скорее всего не получит его вообще, т.к. это уровень на много ниже, чем читатель пакетов СЗ>>К сожаления IP работает так, что если пакет не может собраться из франгментов, то требуется СЗ>>повторение всего пакета заново, никто отдельных фрагмент повторить не может.
JJO>! Уважаемый, вы не тОчны — поясню: JJO>есть _блок_данных_ пользователя JJO>есть IP-пакет(ы) JJO>есть MTU — Maximum Transfer Unit — определяемый физическим уровнем
JJO>так вот, если данные пользователя превышают MTU то IP побъет _блок_данных_ на несколько пакетов и гарантирует целостность заголовков IP-пакетов — определяющих адреса и проч. JJO>Однако! IP НЕ гарантирует целостность данных!
Мне не нужны гарантии целостности. Мне нужна гарантия, что я смогу узнать об ошибке каким либо образом. Просто писать парсер особый я не собираюсь
JJO>Точно также как UDP не дает средств убедиться в том что дошли все пакеты. JJO>Больше того, поскольку UDP это conectionless протокол, то и порядок доставки пакетов — тоже не гарантирован!
Ну и что ? Если IP фрагментирует, то он же и дефргагментирует.
Chapter 1: Overview of TCP/IP: 1.6 Transport layer : 1.6.1 User Datagram Protocol
...
UDP is an unreliable, connectionless datagram protocol. As noted previously, "unreliable"
merely means that there are no techniques in the protocol for verifying that the data
reached the other end of the network correctly.
итого read и все его порождения на клиенте просто прочитают все IP-шные пакеты которые долетят.
и никаких гарантий — ни целостности, ни порядка
JJO>Chapter 1: Overview of TCP/IP: 1.6 Transport layer : 1.6.1 User Datagram Protocol
JJO>...
JJO>UDP is an unreliable, connectionless datagram protocol. As noted previously, "unreliable"
JJO> merely means that there are no techniques in the protocol for verifying that the data
JJO>reached the other end of the network correctly.
JJO>
Это значит, что сидя на одном конце, ты не знаешь, что произойдет на другом.
JJO>итого read и все его порождения на клиенте просто прочитают все IP-шные пакеты которые долетят. JJO>и никаких гарантий — ни целостности, ни порядка
Меня интресует один блок данных, который передается чз конечное количество фрагментов.
Все. Вопрос решен.
IP управляет фрагментацией. Ему абсолютно побоку, какой верхний протокол.
Дефрагментирует он же.
Так что если IP не может собрать все, как было, то и UDP ничего не получит, и TCP и тд.
А recvfrom читает не фрагменты (это IP пакеты), а целый блок данных -UDP. Так что если данные дошли нормально, все прочитается.
[...]
O>Мне не нужны гарантии целостности. Мне нужна гарантия, что я смогу узнать об ошибке каким либо образом. Просто писать парсер особый я не собираюсь
JJO>>Точно также как UDP не дает средств убедиться в том что дошли все пакеты. JJO>>Больше того, поскольку UDP это conectionless протокол, то и порядок доставки пакетов — тоже не гарантирован!
O>Ну и что ? Если IP фрагментирует, то он же и дефргагментирует.
повторяю. с точки зрения IP "недолет" или любые другие проблемы с доставкой пакетов — кроме ошибок маршрутизации или ошибок пришедших с физического уровня — НЕ являются ошибками — IP ни про что другое НЕ ЗНАЕТ.
IP "дефрагментирует" в соответствии с протоколом транспортного уровня — для UDP это означает ... см. уже сказанное в нитке.
похоже без парсера тебе не обойтись — либо перезжай на TCP
Удачи.
Здравствуйте, J.J.OK, Вы писали: JJO>>>Точно также как UDP не дает средств убедиться в том что дошли все пакеты. JJO>>>Больше того, поскольку UDP это conectionless протокол, то и порядок доставки пакетов — тоже не гарантирован!
O>>Ну и что ? Если IP фрагментирует, то он же и дефргагментирует.
JJO>повторяю. с точки зрения IP "недолет" или любые другие проблемы с доставкой пакетов — кроме ошибок маршрутизации или ошибок пришедших с физического уровня — НЕ являются ошибками — IP ни про что другое НЕ ЗНАЕТ.
JJO>IP "дефрагментирует" в соответствии с протоколом транспортного уровня — для UDP это означает ... см. уже сказанное в нитке.
Фрагментируется сообщение именно на IP уровне. Половинки и кусочки IP не пропускает.
Поэтому нельзя гарантировать достоверную доставку.
TCP использует механизм квитирования. Он сам перепосылет IP-пакеты до тех пор, пока не получит ответ или таймаут.
UDP ничего не перепосылает.
Это делаем сами, естественно. Вопрос не в том.
Я забыл про фрагментацию средствами IP.
Если данные фрагментированы, то более высокому протоколу от IP придет полностью дефрагментированный блок.
При дефрагментации используется количество фрагментов и номер фрагмента.
Так что можно гарантировать ( или правильную дефрагментацию или невозмжность такового). Что мне и надо.
А таймауты я буду делать сам.
Вобщем дело не UDP. А в IP
JJO>) похоже без парсера тебе не обойтись — либо перезжай на TCP
А на TCP как это делается ?
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
[...]
JJO>>) похоже без парсера тебе не обойтись — либо перезжай на TCP O>А на TCP как это делается ?
# man tcp
---------------
NAME
tcp - Internet Transmission Control Protocol
SYNOPSIS
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
int
socket(AF_INET, SOCK_STREAM, 0)
DESCRIPTION
The TCP protocol provides reliable, flow-controlled, two-way transmission
of data. .........
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
O>Здравствуйте, J.J.OK, Вы писали:
JJO>>либо MSDN смотри
O>Как с сокетами рубаться я знаю. Мне интересен подпротокол фрагментации и реальная имплементация(те как на самом деле все используется).
в таком случае см. описание протокола RFC 793, Transmission Control Protocol
google + rfc — а там в rfc-index-e посмотри — может есть более свежие RFC-шки на TCP
Здравствуйте, J.J.OK, Вы писали:
JJO>! Уважаемый, вы не тОчны — поясню: JJO>есть _блок_данных_ пользователя JJO>есть IP-пакет(ы) JJO>есть MTU — Maximum Transfer Unit — определяемый физическим уровнем
JJO>так вот, если данные пользователя превышают MTU то IP побъет _блок_данных_ на несколько пакетов и гарантирует целостность заголовков IP-пакетов — определяющих адреса и проч. JJO>Однако! IP НЕ гарантирует целостность данных!
Я и не говорил, что IP гарантирует целостность данных.
Я говорил лишь, что чексумма в UDP будет проверена ядром системы до того, как пакет упадет в стек.
Если чексумма не верная, то получатель ничего не получит,
Если пакет не удается собрать из фрагментов, то получатель тоже ничего не получит.
Чексумму в UDP пакете ставить не обязательно (в TCP обязательно), однако я думаю, что все на сегодня имеющееся системы выставляют в UDP пакете чексумму(это лего можно посмотреть сниффером). Если поле чексумма в пакете не 0, то принимающая сторона обязана проверить чексумму пакета и если она не верна, то пакет уничтожается и ни какая ошибка не генерируется.
Только что заглянул очередной раз в исходники ядра Linux (2.2.19), там все пучком, чуксумма проверяется у UDP пакетов.
JJO>Точно также как UDP не дает средств убедиться в том что дошли все пакеты.
Так и есть. JJO>Больше того, поскольку UDP это conectionless протокол, то и порядок доставки пакетов — тоже не гарантирован!
К тому же я добавлю, что UDP использует IP для пеpедачи сообщения и естественно обеспечивает ту же самую негарантированную доставку пакетов, что и IP. UDP не использует подтвеpждения пpихода сообщений, не упоpядочивает сообщения. Поэтому, UDP сообщения могут быть потеpяны, pазмножены или пpиходить не по поpядку
JJO>[...]
JJO>итого см. мой предыдущий пост.
JJO>Chapter 1: Overview of TCP/IP: 1.6 Transport layer : 1.6.1 User Datagram Protocol
JJO>...
JJO>UDP is an unreliable, connectionless datagram protocol. As noted previously, "unreliable"
JJO> merely means that there are no techniques in the protocol for verifying that the data
JJO>reached the other end of the network correctly.
JJO>
Мой низкий поклон господину O'Reilly. Однако его цитата говорит лишь, о том, что отправитель UDP пакета
не сможет узнать дошел он до получателя или нет, чексумма самого UDP пакета здесь не причем.
JJO>
JJO>итого read и все его порождения на клиенте просто прочитают все IP-шные пакеты которые долетят. JJO>и никаких гарантий — ни целостности, ни порядка
Порядок, да никто не гарантирует. Все надстройки над UDP аля DirectPlay сами "собирают" этот порядок.
Однако я очень сомневаюсь в том, что функции типа read (я думаю автор имел ввиду recv()) что-то вообще получат, в том случае, если пакет не собрался из фрагментов.
похоже без парсера тебе не обойтись — либо перезжай на TCP 