8-900-374-94-44
[email protected]
Slide Image
Меню

Сервера udp – 8.10. Итоговый пример клиент-сервера UDP. UNIX: разработка сетевых приложений

8.10. Итоговый пример клиент-сервера UDP. UNIX: разработка сетевых приложений

8.10. Итоговый пример клиент-сервера UDP

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

Рис. 8.5. Обобщение модели клиент-сервер UDP с точки зрения клиента

Клиент должен задать IP-адрес сервера и номер порта для вызова функции sendto. Обычно клиентский IP-адрес и номер порта автоматически выбираются ядром, хотя мы отмечали, что клиент может вызвать функцию bind. Мы также отмечали, что если эти два значения выбираются для клиента ядром, то динамически назначаемый порт клиента выбирается один раз — при первом вызове функции sendto, и более никогда не изменяется. Однако IP-адрес клиента может меняться для каждой дейтаграммы UDP, которую отправляет клиент, если предположить, что клиент не связывает с сокетом определенный IP-адрес при помощи функции

bind. Причину объясняет рис. 8.5: если узел клиента имеет несколько сетевых интерфейсов, клиент может переключаться между ними (на рис. 8.5 один адрес относится к канальному уровню, изображенному слева, другой — к изображенному справа). В худшем варианте этого сценария IP-адрес клиента, выбираемый ядром на основе исходящего канального уровня, будет меняться для каждой дейтаграммы.

Что произойдет, если клиент с помощью функции bind свяжет IP-адрес со своим сокетом, но ядро решит, что исходящая дейтаграмма должна быть отправлена с какого-то другого канального уровня? В этом случае дейтаграмма IP будет содержать IP-адрес отправителя, отличный от IP-адреса исходящего канального уровня (см. упражнение 8.6).

На рис. 8.6 представлены те же четыре значения, но с точки зрения сервера.

Рис. 8.6. Обобщение модели клиент-сервер UDP с точки зрения сервера

Сервер может узнать по крайней мере четыре параметра для каждой полученной дейтаграммы: IP-адрес отправителя, IP-адрес получателя, номер порта отправителя и номер порта получателя. Вызовы, возвращающие эти сведения серверам TCP и UDP, приведены в табл. 8.1.

Таблица 8.1. Информация, доступная серверу из приходящей дейтаграммы IP

IP-дейтаграмма клиента TCP-сервер UDP-сервер
IP-адрес отправителя accept recvfrom
Номер порта отправителя accept recvfrom
IP-адрес получателя getsockname recvmsg
Номер порта получателя
getsockname
getsockname

У сервера TCP всегда есть простой доступ ко всем четырем фрагментам информации для присоединенного сокета, и эти четыре значения остаются постоянными в течение всего времени жизни соединения. Однако в случае соединения UDP IP-адрес получателя можно получить только с помощью установки параметра сокета IP_RECVDSTADDR для IPv4 или IPV6_PKTINFO для IPv6 и последующего вызова функции recvmsg вместо функции recvfrom. Поскольку протокол UDP не ориентирован на установление соединения, IP-адрес получателя может меняться для каждой дейтаграммы, отправляемой серверу. Сервер UDP может также получать дейтаграммы, предназначенные для одного из широковещательных адресов узла или для адреса многоадресной передачи, что мы обсуждаем в главах 20 и 21. Мы покажем, как определить адрес получателя дейтаграммы UDP, в разделе 20.2, после того как опишем функцию recvmsg.

Поделитесь на страничке

Следующая глава >

it.wikireading.ru

Настройка сведений о портах UDP сервера политики сети

  • Время чтения: 2 мин
  • Соавторы

В этой статье

Относится к: Windows Server (полугодовой канал), Windows Server 2016Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016

Следующая процедура позволяет настроить порты, используемые сервером политики сети (NPS) для удаленной службы проверки подлинности удаленного пользователя (RADIUS) проверки подлинности трафика и учета.You can use the following procedure to configure the ports that Network Policy Server (NPS) uses for Remote Authentication Dial-In User Service (RADIUS) authentication and accounting traffic.

По умолчанию сервер политики сети прослушивает RADIUS-трафик на портах 1812, 1813, 1645 и 1646 для протокол IP версии 6 (IPv6) и IPv4 для всех установленных сетевых адаптеров.By default, NPS listens for RADIUS traffic on ports 1812, 1813, 1645, and 1646 for both Internet Protocol version 6 (IPv6) and IPv4 for all installed network adapters.

Примечание

При удалении IPv4 или IPv6 в сетевом адаптере, NPS не отслеживает RADIUS-трафика для протокола удален.If you uninstall either IPv4 or IPv6 on a network adapter, NPS does not monitor RADIUS traffic for the uninstalled protocol.

Значения порта 1812 для проверки подлинности и 1813 для учета доступны стандартные порты RADIUS, определенные по Internet Engineering Task Force (IETF) в документах RFC 2865 и 2866.The port values of 1812 for authentication and 1813 for accounting are RADIUS standard ports defined by the Internet Engineering Task Force (IETF) in RFCs 2865 and 2866. Тем не менее по умолчанию многие серверы доступа используют порты 1645 для запросов проверки подлинности и 1646 для запросов учета.However, by default, many access servers use ports 1645 for authentication requests and 1646 for accounting requests. Независимо от того, вы решили использовать номера портов убедитесь, что сервер доступа и сервера политики сети настроены на использование одних и тех же.No matter which port numbers you decide to use, make sure that NPS and your access server are configured to use the same ones.

[ВАЖНО] Если вы не используете номера портов по умолчанию RADIUS, необходимо настроить исключения в брандмауэре для локального компьютера, чтобы разрешить трафик RADIUS на новых портов.[IMPORTANT] If you do not use the RADIUS default port numbers, you must configure exceptions on the firewall for the local computer to allow RADIUS traffic on the new ports. Дополнительные сведения см. в разделе настроить брандмауэры для RADIUS-трафика.For more information, see Configure Firewalls for RADIUS Traffic.

Чтобы выполнить эту процедуру, вы должны быть членом группы Администраторы домена или аналогичной.Membership in Domain Admins, or equivalent, is the minimum required to complete this procedure.

Чтобы настроить сведения о порте NPS UDPTo configure NPS UDP port information

  1. Откройте консоль сервера политики сети.Open the NPS console.
  2. Щелкните правой кнопкой мыши сервера политики сети, а затем нажмите кнопку свойства.Right-click Network Policy Server, and then click Properties.
  3. Нажмите кнопку порты вкладку и проверьте параметры портов.Click the Ports tab, and then examine the settings for ports. Если проверка подлинности RADIUS и UDP-порты для учета RADIUS от значения по умолчанию (1812 и 1645 для проверки подлинности и 1813 и 1646 для учета), введите параметры порта в проверки подлинности и Учет.If your RADIUS authentication and RADIUS accounting UDP ports vary from the default values provided (1812 and 1645 for authentication, and 1813 and 1646 for accounting), type your port settings in Authentication and
    Accounting
    .
  4. Чтобы использовать несколько параметров портов для проверки подлинности запросов и учета, запятую номера портов.To use multiple port settings for authentication or accounting requests, separate the port numbers with commas.

Дополнительные сведения об управлении NPS см. в разделе управление сервером политики сети.For more information about managing NPS, see Manage Network Policy Server.

Дополнительные сведения о сервере политики сети, см. в разделе сервера политики сети (NPS).For more information about NPS, see Network Policy Server (NPS).

docs.microsoft.com

сеть — Создание домашнего UDP сервера на C++. Проблемы других компьютеров

Stack Overflow на русском
  1. 0
  2. +0
    • Тур Начните с этой страницы, чтобы быстро ознакомиться с сайтом
    • Справка Подробные ответы на любые возможные вопросы
    • Мета Обсудить принципы работы и политику сайта
    • О нас Узнать больше о компании Stack Overflow
    • Бизнес Узнать больше о поиске разработчиков или рекламе на сайте
  3. Войти Регистрация
  4. текущее сообщество

    • Stack Overflow на русском справка чат

ru.stackoverflow.com

c# — Хороший дизайн сервера ретрансляции UDP

Это очень зависит от масштаба — то есть количества параллельных потоков RTP, которые вы хотите передать. Я разработал именно это решение как часть медиашлюза для нашего SIP-переключателя. Несмотря на первоначальные оговорки, я работаю очень эффективно, используя С# (1000 одновременных потоков на одном сервере, 50 тыс. Дейтаграмм в секунду с использованием 20 мс PTime).

Через пробную ошибку я определил следующее:

1) Использование Socket.ReceiveFromAsync намного лучше, чем использование синхронных подходов, поскольку вам не нужны отдельные потоки для каждого потока. Когда пакеты принимаются, они назначаются через threadpool.

2) Создание/удаление структур SocketAsyncEventArgs требует времени — лучше выделить пул структур при запуске и «заимствовать» их из пула.

3) Аналогично для любых других объектов, требуемых во время обработки (например, класс RTPPacket). Выделение их динамически с такой высокой скоростью приводит к тому, что проблемы с GC возникают довольно быстро с любой реальной нагрузкой. Если вы избегаете всех динамических распределений и вместо этого используете пулы объектов, которыми вы управляете сами, этот вопрос уходит.

4) Если вам нужно выполнить синхронизацию для ввода входных и выходных потоков, транскодирования, микширования или воспроизведения файлов, не пытайтесь использовать стандартные таймеры .NET. Я упаковал таймеры Win32 Multimedia из winmm.dll — они были намного точнее.

Я закончил с архитектурой, где компоненты могли бы разоблачить интерфейсы IRTPSource и IRTPSink, которые затем можно было бы подключить для создания требуемого графика. Я создал компоненты ввода/вывода RTP, микшер, проигрыватель, рекордер, (простой) транскодер, буфер воспроизведения и т.д. — и затем подключил их с помощью этих двух интерфейсов. Затем пакеты RTP синхронизируются по графику с использованием таймеров ММ.

С# оказался хорошим выбором для того, к чему обычно можно обратиться с помощью C или С++.

Mike

qaru.site

Пример клиент TCP и UDP версий клиент-сервера на Python на сокетах.

Всем привет! Сегодня я покажу пример реализации простого клиент-сервера на Python.

Цель:

Реализовать службу Daytime (официальный номер порта 13), как ориентированную, так и не ориентированную на соединение.

Daytime-сервер, ориентированный на соединение прослушивает порт 13. Как только появляется запрос на соединение, сервер принимает запрос и тут же отсылает строку, содержащую информацию о текущем времени и дате. После этого сервер закрывает соединение (все пришедшие во время соединения данные от клиента игнорируются).

Daytime-сервер, не ориентированный на соединение ждет датаграмму на порту 13. Как только появляется сообщение (вся данные в сообщении игнорируются), сервер тут же отсылает строку, содержащую информацию о текущем времени и дате.

Примечание: Стандарт (RFC 867) не устанавливает спецификацию формата возвращаемой строки, но рекомендует чтобы она состояла из печатных ASCII-символов и заканчивалась комбинацией CrLf. Пример строки: “Tuesday, February 22, 1982 17:37:43-PST”.

Исходники:


Клиент сервер на TCP

# -*- coding: utf-8 -*-
__author__ = "dehimer Novikov Denis Yurevich"
# connection-oriented server


import socket
import time 
server_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server_socket.bind(("localhost", 13))
server_socket.listen(5)

print "TCPServer Waiting for client on port 13"

while 1:
    client_socket, address = server_socket.accept()
    have_connect = 1    #if all clients are disconnected
    while have_connect:
        data = client_socket.recv(256)
        print len(data)
        print data
        if (data <> 'Q' and data <> 'q'):
            print "I got a connection from ", address
            data = ('On server now: ' + time.asctime(time.localtime())+ '\n')
            client_socket.send(data)
        else:
            client_socket.close()
            have_connect = 0
            break;
# -*- coding: utf-8 -*-
__author__ = "dehimer Novikov Denis Yurevich"
# connection-oriented client

import socket

client_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
client_socket.connect(('localhost', 13))

while 1:
    
    data = raw_input ( "SEND( TYPE q or Q to Quit):" )
    if (data <> 'Q' and data <> 'q'):
        client_socket.send(data)
        data = client_socket.recv(256)
        print data
    else:
        client_socket.send(data)
        client_socket.close()
        break;

UDP клиент-сервер

# -*- coding: utf-8 -*-
__author__ = "dehimer Novikov Denis Yurevich"
# not a connection-oriented server

import socket
import time

server_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
server_socket.bind(("", 13))

print "UDPServer Waiting for client on port 13"

while 1:
 data, address = server_socket.recvfrom(256)   #receive data and sender's address
 data = ('On server now: ' + time.asctime(time.localtime())+ '\n')
 server_socket.sendto(data, address)
 print  "I got a connection from ( " ,address[0], " " , address[1] , " ) "
# -*- coding: utf-8 -*-
__author__ = "dehimer Novikov Denis Yurevich"
# not a connection-oriented client

import socket
client_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

while 1:

 data = raw_input("Type something(q or Q to exit): ")
 if (data <> 'q' and data <> 'Q'):
  client_socket.sendto(data, ('127.0.0.1', 13))
  data = client_socket.recv(256)                 # receive up to 256 bytes
  print data
 else:
  break
client_socket.close()


Ориентированный на соединение сервер/клиент:

сервер



клиент

Неориентированный на соединение сервер/клиент:

сервер

клиент

Ну вот собственно все=) Дальше покажу пример чата на сокетах, опять же в TCP и UDP версиях.
На вопросы обязательно отвечу в комментариях. Пишите.

dehimer.blogspot.com

udp — Обнаружение UDP-сервера. Должны ли клиенты отправлять многоадресные рассылки, чтобы найти сервер или отправить сервер регулярному маяку?

Оба являются одинаково жизнеспособными методами.

Аргумент для метода # 1 будет состоять в том, что в обычном принципе клиенты инициируют запросы, а серверы слушают и отвечают на них.

Аргумент для метода # 2 будет состоять в том, что точка многоадресной рассылки так, что один хост может отправить пакет, и он может быть получен многими клиентами (один-ко-многим), поэтому он должен быть обратным # 1.

ОК, поскольку я думаю об этом, я на самом деле обращается к №2, инициатору, инициированному сервером. Проблема С# 1 заключается в том, что пусть клиенты передают маяки, и они подключаются к серверу, но сервер либо отключается, либо меняет свой IP-адрес.

Когда сервер будет выполнять резервное копирование и отправит свой первый маяк, все клиенты будут уведомлены в то же время о повторном подключении, и вся ваша система будет немедленно восстановлена. С №1 все клиенты должны индивидуально осознавать, что сервер ушел, и все они будут запускать многоадресную передачу одновременно, пока не будут подключены обратно к серверу. Если бы у вас было 1000 клиентов и 1 сервер, ваша сетевая загрузка в буквальном смысле была бы на 1000 раз больше, чем метод №2.

Я знаю, что эти сообщения, скорее всего, небольшие, и 1000 пакетов за раз ничего не представляют для сети UDP, но только с точки зрения дизайна # 2 чувствует себя лучше.

Изменить: Я чувствую, что здесь я начинаю расстройство раздельного расстройства, но просто подумал о том, что почему 1 было бы преимуществом… Если вы когда-либо хотели реализовать какая-то естественная балансировка нагрузки или масштабирование с несколькими серверами, проект №1 хорошо подходит для этого. Таким образом, первый «доступный» сервер может реагировать на маяк клиента и подключаться к нему, в отличие от №2, где все клиенты переходят на маяковый сервер.

qaru.site

Настройка просмотра IPTV через функцию UDP Proxy


Настройка просмотра IPTV через функцию UDP Proxy в интернет-центрах серии Keenetic с микропрограммой NDMS V2

В микропрограммах, начиная с публичной бета-версии V2.02 (XXX.1)B2, была добавлена функция UDP Proxy (UDP-HTTP прокси) для просмотра IPTV на устройствах и проигрывателях, которые не поддерживают мультикастовые многоадресные рассылки, передаваемые по протоколу UDP. Запрашиваемый таким проигрывателем IPTV-канал будет транслироваться ему через HTTP-соединение. Эта функция бужет полезна для просмотра IPTV на мобильных устройствах, некоторых телевизорах с функциональностью SmartTV и игровых консолях.

Функция UDP Proxy реализована в виде отдельного компонента микропрограммы. Перед началом настройки указанной функции установите компонент UDP-HTTP прокси (udpxy) в веб-конфигураторе интернет-центра в меню Настройки > Компоненты.

Внимание! В интернет-центре может работать только функция IGMP Proxy, либо функция UDP Proxy. То есть перед включением cервера UDP Proxy необходимо отключить IGMP Proxy, и наоборот.

После установки компонента настройка станет доступна в меню Приложения > Сервер udpxy.

Настройки можно использовать по умолчанию, в этом случае udpxy-сервер будет работать в локальной сети по порту 4022, т.е. все клиенты должны будут обращаться по этому номеру TCP-порта.


Настройка проигрывателя на устройствах с ОС Android

Для просмотра IP-телевидения необходимо установить специальное приложение. Одним из наиболее популярных является приложение IPTV, которое можно бесплатно скачать с Google Play.

Программа позволяет загружать плейлист с каналами в формате m3u и проигрывать его с помощью установленных на устройстве видеоплееров, таких, как MX Video Player, Daroon Player, Vplayer и т.п.

После установки приложения необходимо зайти в Настройки.

В подменю Список каналов нужно ввести адрес файла с плейлистом, который предоставил провайдер. В нашем примере используется плейлист http://192.168.10.21:1111/list.m3u

Далее нужно произвести Настройки прокси, указав IP-адрес роутера и порт, на котором работает сервер. В поле Тип прокси укажите UDP-to-HTTP proxy (Windows).

На этом основные настройки программы закончены. Для удобства вы еще можете выбрать в пункте Проигрыватель видео конкретное приложение, с помощью которого будете просматривать видеоконтент.

Настройка проигрывателя (IP-TV Player) на ПК с ОС Windows 

Для просмотра видео на обычном ПК предлагаем воспользоваться программой IP-TV Player: http://borpas.info/iptvplayer-get

После загрузки программы пройдите процедуру установки (Яндекс.Браузер устанавливать не нужно).

После установки программного обеспечения запустите плеер и в качестве провайдера выберите значение Пустой профиль.

В основном окне программы выберите меню настроек (шестеренка в правом нижнем углу).

В появившемся окне Настройки на вкладке Общие поставьте галочку Все настройки, чтобы увидеть расширенные настройки.

Нас интересуют пункты Адрес списка каналов (файл M3U) и Сетевой интерфейс.

В качестве адреса списка каналов используем тот, который предоставил провайдер. В нашем примере используется плейлист http://192.168.10.21:1111/list.m3u

В качестве сетевого интерфейса указываем адрес и порт сервера, работающего на роутере, в нашем случае http://192.168.1.1:4022

После выполнения этих настроек необходимо нажать кнопку Обновить там, где указан адрес плейлиста, и закрыть настройки.
В основном окне программы вы увидите список доступных каналов. Дважды щелкнув по одному из них, вы увидите изображение.

Настройка проигрывателя VLC Media Player на ПК с ОС Windows 

В проигрывателе VLC Media Player можно просматривать каналы, зная их мультикастовые адреса.
Например, мы знаем, что каналы у провайдера имеют такую адресацию:

udp://224.0.0.41:1111
udp://224.0.0.42:1111
udp://224.0.0.43:1111

и так далее.

На роутере с адресом 192.168.1.1 у нас запущен Сервер udpxy на порту 4022, в этом случае для получения видеоконтента необходимо отправлять следующий http-запрос:

http://192.168.1.1:4022/udp/224.0.0.41:1111
http://192.168.1.1:4022/udp/224.0.0.42:1111
http://192.168.1.1:4022/udp/224.0.0.43:1111

и так далее.

В основном меню программы VLC зайдите в меню Медиа > Открыть URL и введите сетевой адрес.

После нажатия кнопки Воспроизвести вы увидите изображение с текущего канала.

Примечание. Работа сервиса udpxy через интерфейс без IP-адреса.

Вопрос: Возможна ли работа сервиса UDP Proxy через интерфейс, на котором отсутствует IP-адрес?
Например, существует интерфейс ISP (ADSL) для цифрового ТВ без IP-адреса и интерфейс PPPoE для подключения Интернета. IGMP-прокси работает. Но при попытке настроить udpxy и выбрать нужный интерфейс, udpxy отключается. В логах можно увидеть следующие сообщения:

Oct 29 04:01:44ndmUdpxy::Manager: a port set to 4022.

Oct 29 04:01:44ndmUdpxy::Manager: a stream timeout set to 5 sec.

Oct 29 04:01:44ndmUdpxy::Manager: a renew subscription interval value disabled.

Oct 29 04:01:44ndmUdpxy::Manager: bound to Switch0/VLAN2.

Oct 29 04:01:44ndmCore::ServiceLock: IPTV is locked by Udpxy.

Oct 29 04:01:44ndmUdpxy::Manager: a service enabled.

Oct 29 04:01:44ndmCore::ConfigurationSaver: saving configuration…

Oct 29 04:01:47ndmService: «Udpxy::Manager» unexpectedly stopped.

Oct 29 04:01:48ndmCore::ConfigurationSaver: configuration saved.

Oct 29 04:01:50ndmService: «Udpxy::Manager» unexpectedly stopped.

Oct 29 04:01:53ndmService: «Udpxy::Manager» unexpectedly stopped.

Oct 29 04:01:56ndmService: «Udpxy::Manager» unexpectedly stopped.

Ответ: Описанная ситуация — это особенность работы сервиса UDP Proxy. Он не может работать без IP-адреса на интерфейсе.

В интернет-центре серии Keenetic можно прописать на интерфейсе для доступа к цифровому ТВ (IPTV) какую-нибудь подсеть (например, 172.16.x.x или 10.10.10.х), которая не пересекается с подсетями на Keenetic и у провайдера.

pokompam.by

Добавить комментарий

Ваш адрес email не будет опубликован.