На главную
ПРАВИЛА FAQ Помощь Участники Календарь Избранное DigiMania RSS
msm.ru
Страницы: (2) 1 [2]  все  ( Перейти к последнему сообщению )  
> Ограничение размера UDP пакета
    Цитата amk @
    то - нет. И там вполне могут ещё действовать правила, установленные почти 50 лет назад.

    Не могут. Законы Мёрфи никто не отменял. Скорость каналов увеличивается. Поэтому стандарты на передачу меняются. Но раз в 10 лет. Вспомнить BASE-10 когда в 80-90 тыг передавали по карбоксилу. А заем ввели витую пару что увеличило надёжность и повысило скорость передачи. И отменило правило 5-4-3.
    А затем Base-100 что добавило избыточное кодирование. И вообще переход на оптику и введения стандарта BGP и AS.


    Цитата amk @
    Это ничего не значит. Пакет, в теории, может проходить через соединения, где IP-пакет заворачиваются в пакеты другого типа. Причём может оказаться, что пакет должен заворачиваться целиком, без разрезания. Тогда максимальная длина пакета дополнительно ограничится. Причём с большой вероятностью такое соединение, если существует, существует не физически, а чисто программно.

    В теории не может. Есть стандарты и комитеты по развитию интернета.
    И то что происходит на магистральных линиях хорошо известно. А там пакеты собираются в группы так как их быстрее обрабатывать пачками, а не по отдельности. А во вторых фильтрацию на магистрали не делают. Физически из-за скорости не возможно. Для этого есть AS. На уровне IP пакеты раскидываются по AS. А вот сборка пакета уже выполняет AS и она решает отбросить его или нет.

    А да на магистрали пакет пропасть не может, только побиться.
    Правильный обед должен состоять из 5 блюд приготовленных из 33 ингредиентов.
      Длина пакета "чем больше тем лучше" для уменьшения накладных расходов.
      Не хочу чтобы при пакетах по 2 Кб был огромный PPS - это нагрузка и на моем оборудовании, и на оборудовании всех промежуточных сетей.

      Почему UDP? Сойдет любой протокол с датаграммами (без установки соединения) но в этом случае UDP это самое простое что можно сделать.
      hello world
        Виталь
        Всё равно больше размера MTU не пропихнёшь пакет по сети, большие пакеты будут дробиться и собираться обратно тем же оборудованием. Смысл теряется - лучше слать максимальный пакет, умещающийся в MTU.
          Цитата Марсианин @
          улетел из приложения пакет 15кб маршрутизатор побил его на 10 по 1,5кб и отправил адресату.

          Не может из приложения улететь пакет 15 кб одним куском. :)
          Везде в сетевых настройках есть MTU, и все IP-пакеты уходят с компа по 1460 байт полезной нагрузки.
          Я опишу Винду.
          Инициализация сетевого приложения производится:
          int WSAStartup (WORD wVersionRequested, LPWSADATA lpWSAData);
          В структуре
          ExpandedWrap disabled
            typedef struct WSAData
            {
              WORD              wVersion;
              WORD              wHighVersion;
              char              szDescription[WSADESCRIPTION_LEN+1];
              char              szSystemStatus[WSASYS_STATUS_LEN+1];
              unsigned short    iMaxSockets;
              unsigned short    iMaxUdpDg;
              char FAR *        lpVendorInfo;
            } WSADATA;
            typedef WSADATA  FAR *LPWSADATA;

          есть возвращаемый параметр iMaxUdpDg, который при желании можно посмотреть.
          Так вот, для многих реализаций сокетов Berkeley имеется неявный предел в 8192 байтов на UDP-датаграммы (которые затем могут быть фрагментированы в случае необходимости). Реализация сокетов Windows может наложить свой предел, основанный, например, на распределении буферов повторной сборки фрагмента. Минимальное значение iMaxUdpDg для совместимых реализаций Windows Sockets – 512. Обратите внимание, что независимо от значения iMaxUdpDg, нецелесообразно пытаться посылать широковещательную датаграмму, которая больше чем MTU сети. (API Windows Sockets не обеспечивает механизм обнаружения MTU, но он должен быть не меньше чем 512 байтов.) Отметим, ...что iMaxUdpDg в версии WinSock 2.0 не используются и остались только для совместимости с версией 1.1
          ========================================
          Т.е. все про UDP выше уже устарело.
          Т.е. можно конечно же посмотреть, какую датаграмму виндовс дает возможность хранить одним куском в буфере сокета. С другой стороны, этот размер буфера сокета можно изменять по своему соображению, так как если использовать интерфейс WinSock 2.0 и выше - а эти интерфейсы сейчас у всех виндов - то можно в общем то и не заморачиваться или использовать setsockopt() для размера буфера.
          Конечно же есть проблема на получателе - в размере буфера приема сокета приемника. Если в него не влазит принимаемая с помощью нескольких IP-пакетов одна датаграмма, то функция recvfrom() не сможет вернуть управление и датаграмма будет отвергнута. Думаю что ваши проблемы именно в этом - провайдер скорее всего не причем. Пров пересылает IP-пакеты с любыми протоколами внутри, а вот на конце это может быть проблема.
          Где-то вот так. :)
          Надо смотреть на приемнике - какой у него по умолчанию буфер приема для UDP-сокета. Обычно он где-то 8Кб
          Сообщение отредактировано: Oleg2004 -
          GOD IS GOOD! IN ALL THE TIME!
            Апну так как проблема в корне все еще не решена, а отложена.
            Программа - отправитель и программа - получатель. Одна и та же программа-получатель с одними и теми же буферами стоит на 2 разных машинах, только на одной пакет принимается, а на другую не доходит. Виноват именно провайдер, собственно от его услуг по этой и некоторым другим причинам я пару месяцев назад и отказался. Да, возможно где-то посредине кривая реализация чего-то и размер принимается как целое со знаком, плюс еще какие-то факторы...

            Что касается пакетов - возможно действительно стоит пренебречь PPS"ом и слать пакеты поменьше.
            Сообщение отредактировано: Виталь -
            hello world
              Виноват не провайдер, а ТС. Если кратко, udp не гарантирует что пакет будет доставлен. Хочешь гарантированной доставки? Используй силуtcp, Люк. Но даже в случае тцп, еcли размер пакета превысит мту, он будет фрагментирован, если конечно ты не догадался поставить флаг DF, в таком случае он будет просто дропнут.

              Добавлено
              Цитата Виталь @
              Вот я и думаю, проектировать ли сразу приложение под автоматический подбор длины пакета, или же остановиться на каком-то гарантированно проходящем...

              А я вот думаю предоставить ОС самой формировать и отправлять пакеты. Самому же сделать микропротокольчик поверх тцп чисто для контроля целостности передаваемых данных, и тогда вопрос про размер пакета отпадёт сам собой.
              Сообщение отредактировано: Gonarh -
                Цитата
                А во вторых фильтрацию на магистрали не делают. Физически из-за скорости не возможно. Для этого есть AS. На уровне IP пакеты раскидываются по AS. А вот сборка пакета уже выполняет AS и она решает отбросить его или нет.

                Какая же у тебя каша в голове.
                1. Фильтрацию уже давно можно делать на wirespeed, по крайней мере на 10G-линках точно, для этого применяются асики с ткамами.
                2. AS к фильтрации не имеет никакого отношения. Совсем. Никак. Это всего лишь 16-битное, а сейчас и 32-битное число, выданное риром, в нашем случае райпом. Применяется в маршрутизации интернет трафика по протоколу BGP.
                1 пользователей читают эту тему (1 гостей и 0 скрытых пользователей)
                0 пользователей:


                Рейтинг@Mail.ru
                [ Script Execution time: 0,0938 ]   [ 14 queries used ]   [ Generated: 14.11.18, 02:39 GMT ]