8-900-374-94-44
8.10. Итоговый пример клиент-сервера UDP
На рис. 8.5 крупными черными точками показаны четыре значения, которые должны быть заданы или выбраны, когда клиент отправляет дейтаграмму UDP.
Рис. 8.5. Обобщение модели клиент-сервер UDP с точки зрения клиента
Клиент должен задать IP-адрес сервера и номер порта для вызова функции sendto. Обычно клиентский IP-адрес и номер порта автоматически выбираются ядром, хотя мы отмечали, что клиент может вызвать функцию bind. Мы также отмечали, что если эти два значения выбираются для клиента ядром, то динамически назначаемый порт клиента выбирается один раз — при первом вызове функции sendto, и более никогда не изменяется. Однако IP-адрес клиента может меняться для каждой дейтаграммы UDP, которую отправляет клиент, если предположить, что клиент не связывает с сокетом определенный 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 |
У сервера TCP всегда есть простой доступ ко всем четырем фрагментам информации для присоединенного сокета, и эти четыре значения остаются постоянными в течение всего времени жизни соединения. Однако в случае соединения UDP IP-адрес получателя можно получить только с помощью установки параметра сокета IP_RECVDSTADDR для IPv4 или IPV6_PKTINFO для IPv6 и последующего вызова функции recvmsg вместо функции recvfrom. Поскольку протокол UDP не ориентирован на установление соединения, IP-адрес получателя может меняться для каждой дейтаграммы, отправляемой серверу. Сервер UDP может также получать дейтаграммы, предназначенные для одного из широковещательных адресов узла или для адреса многоадресной передачи, что мы обсуждаем в главах 20 и 21. Мы покажем, как определить адрес получателя дейтаграммы UDP, в разделе 20.2, после того как опишем функцию recvmsg.
Следующая глава >
it.wikireading.ru
Относится к: 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 см. в разделе управление сервером политики сети.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
ru.stackoverflow.com
Это очень зависит от масштаба — то есть количества параллельных потоков 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
Цель:
Реализовать службу 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
Оба являются одинаково жизнеспособными методами.
Аргумент для метода # 1 будет состоять в том, что в обычном принципе клиенты инициируют запросы, а серверы слушают и отвечают на них.
Аргумент для метода # 2 будет состоять в том, что точка многоадресной рассылки так, что один хост может отправить пакет, и он может быть получен многими клиентами (один-ко-многим), поэтому он должен быть обратным # 1.
ОК, поскольку я думаю об этом, я на самом деле обращается к №2, инициатору, инициированному сервером. Проблема С# 1 заключается в том, что пусть клиенты передают маяки, и они подключаются к серверу, но сервер либо отключается, либо меняет свой IP-адрес.
Когда сервер будет выполнять резервное копирование и отправит свой первый маяк, все клиенты будут уведомлены в то же время о повторном подключении, и вся ваша система будет немедленно восстановлена. С №1 все клиенты должны индивидуально осознавать, что сервер ушел, и все они будут запускать многоадресную передачу одновременно, пока не будут подключены обратно к серверу. Если бы у вас было 1000 клиентов и 1 сервер, ваша сетевая загрузка в буквальном смысле была бы на 1000 раз больше, чем метод №2.
Я знаю, что эти сообщения, скорее всего, небольшие, и 1000 пакетов за раз ничего не представляют для сети UDP, но только с точки зрения дизайна # 2 чувствует себя лучше.
Изменить: Я чувствую, что здесь я начинаю расстройство раздельного расстройства, но просто подумал о том, что почему 1 было бы преимуществом… Если вы когда-либо хотели реализовать какая-то естественная балансировка нагрузки или масштабирование с несколькими серверами, проект №1 хорошо подходит для этого. Таким образом, первый «доступный» сервер может реагировать на маяк клиента и подключаться к нему, в отличие от №2, где все клиенты переходят на маяковый сервер.
qaru.site
В микропрограммах, начиная с публичной бета-версии 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-адрес?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