Использование служб UDP Use UDP services

Класс UdpClient взаимодействует с сетевыми службами по протоколу UDP. The UdpClient class communicates with network services using UDP. Методы и свойства класса UdpClient абстрагируют сведения о создании Socket для запроса и получения данных по протоколу UDP. The properties and methods of the UdpClient class abstract the details of creating a Socket for requesting and receiving data using UDP.

UDP — это простой протокол для максимально эффективной передачи данных в удаленный узел. User Datagram Protocol (UDP) is a simple protocol that makes a best effort to deliver data to a remote host. Однако поскольку протокол UDP не предусматривает установление соединений, доставка датаграмм UDP, отправляемых в удаленную конечную точку, не гарантируется. Кроме того, не гарантируется их доставка в той же очередности, в которой они отправлялись. However, because the UDP protocol is a connectionless protocol, UDP datagrams sent to the remote endpoint are not guaranteed to arrive, nor are they guaranteed to arrive in the same sequence in which they are sent. Приложения, использующие протокол UDP, должны быть готовы обрабатывать отсутствующие, повторяющиеся и идущие не по порядку датаграммы. Applications that use UDP must be prepared to handle missing, duplicate, and out-of-sequence datagrams.

Чтобы отправить датаграмму по протоколу UDP, необходимо знать адрес сетевого устройства, в котором размещается нужная служба, и номер порта UDP, который служба использует для обмена данными. To send a datagram using UDP, you must know the network address of the network device hosting the service you need and the UDP port number that the service uses to communicate. Номера портов для основных служб определяются организацией IANA («Администрация адресного пространства Интернет»). См. документ Service Name and Transport Protocol Port Number Registry (Реестр названий служб и номеров портов транспортных протоколов). The Internet Assigned Numbers Authority (IANA) defines port numbers for common services (see Service Name and Transport Protocol Port Number Registry). Службы, отсутствующие в списке IANA, могут иметь номера портов в диапазоне от 1024 до 65535. Services not on the IANA list can have port numbers in the range 1,024 to 65,535.

Для поддержки широковещательных сообщений UDP в IP-сетях используются специальные сетевые адреса. Special network addresses are used to support UDP broadcast messages on IP-based networks. Далее в качестве примера используется семейство адресов IP версии 4. The following discussion uses the IP version 4 address family used on the Internet as an example.

В IP версии 4 для указания сетевых адресов используются 32 бита. IP version 4 addresses use 32 bits to specify a network address. Для адресов класса C с маской сети 255.255.255.0 эти биты разделяются на четыре октета. For class C addresses using a netmask of 255.255.255.0, these bits are separated into four octets. В десятичной форме эти четыре октета образуют знакомую нотацию с использованием четырех чисел, разделенных точками, например 192.168.100.2. When expressed in decimal, the four octets form the familiar dotted-quad notation, such as 192.168.100.2. Первые два октета (192.168 в этом примере) — это номер сети, третий октет (100) — это подсеть, а последний октет (2) — идентификатор узла. The first two octets (192.168 in this example) form the network number, the third octet (100) defines the subnet, and the final octet (2) is the host identifier.

Если задать все биты IP-адреса равными единице (то есть 255.255.255.255 в десятичной форме), получится ограниченный широковещательный адрес. Setting all the bits of an IP address to one, or 255.255.255.255, forms the limited broadcast address. При отправке датаграммы UDP на этот адрес сообщение доставляется всем узлам в сегменте локальной сети. Sending a UDP datagram to this address delivers the message to any host on the local network segment. Так как маршрутизаторы никогда не перенаправляют сообщения, отправляемые на этот адрес, широковещательное сообщение получают только узлы в этом сегменте сети. Because routers never forward messages sent to this address, only hosts on the network segment receive the broadcast message.

Для направления широковещательных сообщений в определенные части сети можно задать все биты идентификатора узла. Broadcasts can be directed to specific portions of a network by setting all bits of the host identifier. Например, для отправки широковещательного сообщения всем узлам в сети, которая определяется IP-адресами, начинающимися с 192.168.1, используйте адрес 192.168.1.255. For example, to send a broadcast to all hosts on the network identified by IP addresses starting with 192.168.1, use the address 192.168.1.255.

В приведенном ниже примере кода используется объект UdpClient для прослушивания датаграмм UDP через порт 11000. The following code example uses a UdpClient to listen for UDP datagrams on port 11,000. Клиент получает строку сообщения и выводит сообщение в консоли. The client receives a message string and writes the message to the console.

В приведенном ниже примере кода используется объект Socket для отправки датаграмм UDP на направленный широковещательный адрес 192.168.1.255 через порт 11000. The following code example uses a Socket to send UDP datagrams to the directed broadcast address 192.168.1.255, using port 11,000. Клиент отправляет строку сообщения, указанную в командной строке. The client sends the message string specified on the command line.

Подключение микроконтроллера к локальной сети: UDP-клиент

В этой части мы продолжим писать наш стек протоколов. Добавим возможность отправлять UDP-пакеты на любой IP-адрес и научимся получать данные с удалённого сервера.

• Введение в роутинг
• ARP-ресолвер
• Отправка пакетов
• Пример работы со стеком
• Заключение

Маршрутизация в Internet

Немножко теории. Рассмотрим основы роутинга в Internet. Думаю, большинство читателей могут эту часть спокойно пропустить)

Итак, возьмём, для примера, мою домашнюю сеть.

Допустим, комп знает IP-адрес девайса и хочет отправить ему пакет. При этом происходит следующее:

• Комп убеждается, что девайс находится в той же локальной сети, что и он сам.
• С помощью ARP, комп определяет MAC-адрес девайса.
• Комп заворачивает IP-пакет в Ethernet-фрейм и отрпавляет на MAC-адрес девайса.
• Девайс получает фрейм, видит в нём IP-пакет, в котором в качестве адреса получателя указан его собственный IP-адрес.
• Полученный IP-пакет передаётся протоколу транспортного уровня (UDP, etc.) и, затем, приложению.

Как комп определяет, что девайс находится с ним в одной локальной сети? Любой IP-адрес состоит из адреса подсети и адреса хоста. Именно адрес подсети определяет принадлежность IP-адреса к конкретной локальной сети.

Для выделения адреса подсети из IP-адреса служит маска подсети. Накладываем на IP-адрес маску и получаем адрес подсети.

В моей домашней сетке маска равна 255.255.255.0. Соответственно, адрес подсети равен 192.168.0.0, а допустимые IP-адреса — от 192.168.0.1 до 192.168.0.254 (первый и последний адреса зарезервированы). Видя, что адрес девайса относится к этому промежутку, комп и понимает — девайс находится с ним в одной локальной сети.

Но что, если мы хотим отправить пакет узлу, который находится не в нашей локальной сети, а вообще неизвестно где? Рассмотрим вот такую сеть (случай не то, чтобы очень жизненный, зато наглядный):

Запись вроде 192.168.3.0/24 означает подсеть с адресом 192.168.3.0 и маской 255.255.255.0 (24 бита установлено).

Допустим, 192.168.0.33 хочет отправить пакет узлу 192.168.3.3, находящемуся в сети 192.168.3.0. Происходит следующее:

• 192.168.0.33 записывает в IP пакет адрес отправителя 192.168.0.33 (свой), а адрес получателя — 192.168.3.3. Ничего необычного.
• Заворачивает пакет в Ethernet-фрейм и отправляет его на MAC-адрес узла 192.168.0.22.
• 192.168.0.22 получает фрейм, видит в нём пакет, предназначеный 192.168.3.3. Поскольку он подключен к обоим локальным сетям, он просто пересылает пакет узлу 192.168.3.3.

Как 192.168.0.33 узнает кому пересылать пакет? Для этого у него есть таблица роутов. Выглядит она примерно так:

Когда узел хочет отправить пакет в другую сеть, он просматривает свою таблицу роутов. В ней он находит адрес узла (гейт), на который нужно переслать пакет, чтобы он попал в нужную сеть. Последняя запись — роут по-умолчанию (default route). Она определяет основной гейт (default gateway) — узел, на который пересылаются все пакеты, роут для которых не прописан в явном виде.

Вернёмся к нашей сети. Все пакеты, выходящие за пределы сети проходят через роутер (192.168.0.1), он-то и является основным гейтом. Дополнительные роуты нам прописывать ни к чему, для отправки пакетов наружу достаточно знать адрес основного гейта.

Собирая вместе всё вышесказанное, можно отметить: для полноценной работы наш девайс должен знать три вещи — свой IP-адрес, маску подсети и IP-адрес основного гейта. Маска подсети используется, чтобы определять, относится ли определённый IP-адрес к нашей локальной сети. Все пакеты, выходящие за пределы локальной сети мы пересылаем основному гейту.

ARP-ресолвер

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

Алгоритм работы нашего ARP-ресолвера будет следующий:

• Когда нам нужно определить MAC-адрес узла, ищем его в ARP-кэше по IP-адресу.
• Если узел найден в кэше, просто возвращаем его MAC-адрес.
• Если узел в кэше не найден, посылаем широковещательный ARP-запрос, чтобы найти нужный узел.
• Получив ответ на наш запрос, добавляем узел в ARP-кэш.

Добавлять узлы в ARP-кэш будем по кругу (т.е при добавлении новой записи, самая старая будет затираться).

Проверять валидность записей кэша мы не будем — врядли MAC-адрес какого-либо узла внезапно изменится.

Отправка пакетов

Теперь мы готовы отправлять IP-пакеты любым узлам, подключенным к интернету. Для начала, нам понадобится определить наш IP-адрес, маску подсети и основной гейт.

Алгоритм отправки IP-пакета будет простой:

• Определяем IP-адрес узла, на который будем отправлять Etheret-фрейм, содержащий пакет. Если пакет пересылается в пределах локальной сети, сразу посылаем его нужному узлу. Иначе будем отправлять фрейм основному гейту.
• Ресолвим MAC-адрес узла.
• Заворачиваем IP-пакет в Ethernet-фрейм и посылаем.

Ну и отправка UDP-пакета.

Пишем приложение

Чисто чтобы потестить наш улучшенный стек, попробуем получить какую-нибудь информацию из интернета. Например, точное время по NTP.

NTP реализуем самым тупым способом — отрпавляем серверу запрос, получаем ответ с точным временем. Для правильной работы NTP, локальный UDP-порт не должен равняться UDP-порту сервера (123). Также, нужно учитывать, что NTP возвращает неправильный timestamp — количество секунд, прошедших с 1 января 1900 года. Чтобы получить нормальный timestamp, считающийся с 1 января 1970, года, нужно отнять от NTP-timestamp’а ровно 2208988800 секунд.

С помощью NTP, будем запрашивать время каждые 12 часов.

Потестируем то, что получилось.

Заключение

Скачать проект можно тут.

В следующей части мы немного отвлечёмся от микроконтроллеров и посмотрим как можно общаться с сетевыми девайсами со стороны компа.

Windows BAT or CMD: send some data to a localhost udp port

I have an app that listens on a localhost port. I want a minimal launcher to bring that app’s to the front.

My app is in Java. I don’t know how to write any exe files, but I can write bat files, and then make a shortcut that launches the bat file without showing the terminal. I would like to have the bat file send some data to a port (preferably UDP so there will not be any stream overhead).

How can I send data to a UDP port?

One of the things I thought of was nslookup , but that will only connect to port 53 as far as I know.

This only needs to work on Windows. Would like it to work on XP and up, but I can make a workaround if necessary.

3 Answers 3

This is a job for netcat.

After installing you can easily launch it from the command line or write a BAT script to execute it for you. To send date through UDP rather than TCP, use the «-u» switch.

For example, to send the data to UPD port 2345 on localhost execute:

Then type the data you want to send.

I was having quite a few problems sending a UDP command to a Brightsign digital sign with netcat. I ended up using Swiss File Knife. It is possible I had the syntex wrong with my netcat statement. (If anyone could suggest the correct syntax based on my working SFK statement, I would love to know) I just wanted to send a few asci key words to my sign from a batch file. My sign was 192.168.1.22 and listening on port 5000

Here are my working steps:

Copied the file to C:\tools and renamed the sfk174.exe file to skf.exe(to make is shorter) and used the bellow syntax to send the UDP command Special

C:\tools\sfk udpsend 192.168.1.22 5000 “Special” (make sure you put your asci word in quotes. it will work without but not for words with spaces between)

I put the commands in a batch file and created a windows icon for the customer and they worked great.

Sending TCP/UDP packets using Netcat

There are a number of protocols powering the Internet of Things. Choosing the right one will depend on your project’s security, bandwidth and reliability needs, or maybe just your device computing limitations. In some cases like cellular transmission, the good old TCP/UDP packet transmission will work just fine. This article will show you how to simulate a client using a useful tool called Netcat and realize the immediate connection using your own computer’s terminal.

To learn how to send data to Ubidots using these protocols, see Send Data to Ubidots over TCP or UDP.

Netcat is a featured networking utility which reads and writes data across network connections, using the TCP/IP protocol. Designed to be a reliable «back-end» tool, Netcat can be used directly with other programs and scripts to send files from a client to a server and back. At the same time, it is a feature-rich network debugging and exploration tool that can specify the network patameters while also establishing a connection to a remote host via a tunnel.

Although Netcat can do many things, its main purpose and most desirable function is to:

1. Create an initial socket to establish a connection from server to the client.
2. Once connected, Netcat will automatically generate a second socket to transmit files from the server to the client and visa versa. (This is the really cool part.)

Reference below for a diagram of the data Netcat protocol architecture.

Something so simple happens to be extraordinarily powerful and flexible as you will see below. For simplicity, local connections are used, although, of course, they can be used between different machines.

Syntax

nc [-options] hostname port[s] [ports]
nc -l -p port [-options] [hostname] [port]

Basic parameters

• —l: set the «listen» mode, waits for the incoming connections.
• —p: local port
• —u: set the UDP mode

Test your Netcat understanding as a client-server

Open two computer terminals, the first will act as the server and the second will be the client.

TCP client

With Netcat your PC can be converted in a server, you want to begin as a server that listens at port 2399:

In addition, we can use the server to connect to the port (2399) recently opened, from the client side:

As you can see on the image below, the connection is established:

With the connection established you are now able to write to the server from the client:

In the terminal where the server is running, your text files will appear seamlessly.

UDP client

By default Netcat uses the TCP protocol for its communications, but it can also UDP using the -u option.

As we mentioned at the previous step, Netcat lets you convert your PC in a server. In this case we’re going to establish the connection between the server and the client but using UDP.

From the server side, run the command below. As you can see, the command establishes the UDP connection just requires the -u to be added to the command:

Once you start the server, establish the connection with the client:

Now the client and the server are using UDP protocol for their communication. You can verify commincation using the netstat command in a new (3rd) computer terminal.

$ netstat | grep 2399
udp 0 0 localhost:2399 localhost:57508 ESTABLISHED

As you can see in the images below, the message is received by the server, and the transmission is verified by the connection:

With this introduction to Netcat, you now have a better understanding of this advanced tool to send data quickly and efficiently between client and server. For additional information, check out this link.

This article was originally published on Ubidots’ Blog on June 22, 2017.