Вход Наше всё Теги codebook 无线电组件 Поиск Опросы Закон Пятница
19 апреля

О смысле всего сущего 0xFF Средства и методы разработки Мобильная и беспроводная связь Блошиный рынок Объявления

Микроконтроллеры PLD, FPGA, DSP AVR PIC ARM, RISC-V Технологии Кибернетика, автоматика, протоколы Схемы, платы, компоненты

Мобильная и беспроводная связь

915691 Топик полностью

Гудвин, волшебник (13.04.2019 11:11, просмотров: 252) ответил blackprapor на а с какого порта клиент отправляет данные, на какой принимает, и с какого при этом получает сервер и на какие сам отвечает?

В данный момент на сервере 777, у терминалов 1000.

Ответить

- я не про то спросил, возможно неверно сформулировал. конкретный номер не очень интересует, blackprapor(841 знак., 13.04.2019 11:34 - 11:44)
  - Сервер принимает на одном порту, ответ отправляет на тот порт, с которого принята дейтаграмма. Сокет на сервере один, на клиенте тоже. Адреса во время сессии не меняются - то что выдал опсос во время установки соединения. - Гудвин(13.04.2019 12:22)
    - Да, странно, всё выглядит так, что работать должно без сучка и задоринки. а промежуток времени между посылкой клиента и ответом сервера, всё же каков? - blackprapor(13.04.2019 12:34)
      - Вот снял кусочек видео "пинг-понга". Это окно консоли сервера и "дудкИ" девайса. Интервал 3 сек, порты на севере и клиенте=10000, короткий пакет.(Оторожно - 37 метров). С пакетами длиной 512 байт и интервалом 10 сек. ситуация была почти красивой, Гудвин(53 знак., 13.04.2019 13:27 - 13:29, ссылка)
        
        может, проблема всё же на канальном уровне? ну, там, с качеством связи чтотоо. я не очень понимаю, почему при указанных условиях не должно проходить через нат, условия самые благоприятные, если только преднамеренно не отбрасываются пакеты или blackprapor(16 знак., 13.04.2019 13:52)
        
        Намереваюсь сейчас посмотреть ID и TTL IP заголовка пакетов, который выдает стек Keil. - Гудвин(13.04.2019 14:09)
        
        Интересно, а обмен, замаскированный под DNS udp запросы и ответы, у них тоже будут проходить раз через раз? - blackprapor(13.04.2019 17:00)
        
        Таки луникс - вещь! Млять, в отличии от винды достаточно наткнуть всего-навсего "tcpdump udp -n -v". Вот 2 последовательные посылки: Гудвин(1008 знак., 13.04.2019 16:20)
      - Когда как - сотовая... Иногда сразу, иногда через пару секунд. Иногда никогда :) - Гудвин(13.04.2019 12:51)
        
        я имел в виду промежуток между получением сервером запроса и его же ответом. как понимаю, сервер отвечает сразу же? уж, по крайней мере, несколько секунд запись в таблице нат должна храниться. слеедовательно, "мгновенный", ответ должон проходить blackprapor(9 знак., 13.04.2019 13:22)
        
        Да - сервер отвечает сразу после приема. - Гудвин(13.04.2019 13:32)
- Сейчас попробую SIP-овский 5060 на сервере, и 10000...20000 на клиенте. Возможно у опсоса какие то особые правила для SIP. - Гудвин(13.04.2019 11:18)
  - для некоторых протоколов типа sip некоторые nat действительно иногда используют особые методы обработки, связано с тем, что адреса в этих протоколах используются еще и внутри пакета ппротокола и простой заменой локального адреса в ip пакете на blackprapor(44 знак., 13.04.2019 11:54)
    - Гы :) Попробовал. Ситуация примерно такая же. Но появилась задержка времени доставки на сервер и на сервере вывалилось вот такое (внутри). Мой серверок "голый" - только один UDP порт открыт наружу. Это уже "довесок" от опсоса похоже. Гудвин(498 знак., 13.04.2019 12:39 - 12:43)
      - ну да, а ваши пакеты от сервера "левыми "похоже приходят другим. blackprapor(97 знак., 13.04.2019 13:30)