Пакеты UDP от полевого устройства не будут проходить через инфраструктуру Azure к моему сервису - PullRequest
Новая
       35

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

0 голосов
/ 16 мая 2019

Полевое устройство (Loxone miniserver) отправляет измерения в пакетах UDP на общедоступный адрес виртуальной машины Azure и на мой локальный компьютер, оба на порт 1234 (изменено для целостности).На моей локальной машине в той же сети, что и полевое устройство, я реализовал тестовый приемник в C #, который правильно получает пакеты.В уже запущенном приложении на лазурной виртуальной машине я добавил тот же код получателя, что и на локальной машине, и не получил пакетов UDP.Что я уже сделал на платформе управления Azure: - разрешил входящий порт 1234 в конфигурации сети; - отключил брандмауэр

. Для тестирования я попробовал следующее: - внедрил отправителя UDP в приложении на виртуальной машине Azure, которыйотправляет по широковещательному IP на порт 1234 -> это работает!- Добавлен пакетный монитор к сетевому интерфейсу -> здесь я вижу оба пакета, внутреннюю рассылку и полевое устройство

// Код получателя сокращен до соответствующих частей 

class Program{
    public static void Main(string[] args){
        program.Run();
    }

    public void Run(){
        var sync = new LoxoneSyncProcess();
        while(true){
            sync.readUDP();
            Thread.sleep(10000);
        }
    }
}


class LoxoneSyncProcess{
    public LoxoneSyncProcess(){
        private UDPSocket c = new UDPSocket();
        c.Client(1234);
    }

    public void readUDP(){
        String buffer = c.getDatBuf();
        Console.WriteLine(buffer);
        //process buffer
    }
}


public class UDPSocket{
    private Socket _socket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
    private const int bufSize = 8 * 1024;
    private State state = new State();
    private EndPoint epFrom = new IPEndPoint(IPAddress.Any, 0);
    private AsyncCallback recv = null;
    private String datBuf = "";

    public class State
    {
        public byte[] buffer = new byte[bufSize];
    }

    public String getDatBuf()
    {
        String temp = datBuf;
        datBuf = "";
        return temp;
    }

    public void Client(int port)
    {
        _socket.Bind(new IPEndPoint(IPAddress.Any, port));
        Receive();
    }

    private void Receive()
    {
        _socket.BeginReceiveFrom(state.buffer, 0, bufSize, SocketFlags.None, ref epFrom, recv = (ar) =>
        {
            State so = (State)ar.AsyncState;
            int bytes = _socket.EndReceiveFrom(ar, ref epFrom);
            _socket.BeginReceiveFrom(so.buffer, 0, bufSize, SocketFlags.None, ref epFrom, recv, so);
            datBuf += Encoding.ASCII.GetString(so.buffer, 0, bytes);
            //Console.WriteLine("RECV: {0}: {1}, {2}", epFrom.ToString(), bytes, Encoding.ASCII.GetString(so.buffer, 0, bytes));
        }, state);
    }
}

код работает, я получаю самостоятельно отправленные пакеты UDP на порт 1234 по Broadcast-IP, но не от полевого устройства.Нужны ли какие-либо таблицы, подобные NAT-конфигурации?Или портпереход?Поддерживает ли Azure общедоступные конечные точки UDP?

1 Ответ

0 голосов
/ 21 мая 2019

Открытая конечная точка UDP поддерживается в Azure.Просто хотел проверить размер полезной нагрузки UDP, которую вы используете.Если полезная нагрузка UDP составляет> 1500 байт, то она не будет работать.

В данный момент это сделано специально, поскольку мы не поддерживаем фрагменты для публичных конечных точек VIP прямо сейчас в vswitch.Рекомендуется, чтобы клиенты сохраняли дейтаграммы UDP до 1500. На самом деле мы ничего не можем сделать, чтобы фрагменты проходили без изменений кода - они принципиально не поддерживаются в NAT

...