Reading UDP Packets

[IJRobson]

I have some Hardware that is sending UDP Packets that contain Test information I am trying to read from a WinBatch Application.

I have a working Python Script that reads the packet Data so I know the Hardware is sending packets:

Code Select Expand

### JUST A SERVER TO RECEIVE TEST DATA  ###
import socket

UDP_IP = "192.168.2.2"
UDP_PORT = 7777

SeverSocket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

SeverSocket.bind((UDP_IP, UDP_PORT))

while True:
    data, addr = SeverSocket.recvfrom(2048)
    print (data,)


So now I am trying to work out a way to read this Data using WinBatch. 

I could go down the route of running the Python Script from a Prompt and piping the Output from the Script into WinBatch but using the WinSock Extender sounds like a better method.  I have had a play with the extender but it never reads any Data.  Will the Extender Support UDP Packets?

Another option is MSWinSock.  Using this I can get it to trigger on Data and read data using .GetData() but this only reads some of the packets thus lots of Data is being missed.

Any ideas?

Thanks

[td]

The WinSock extender does not support UDP.  You could check out the .Net socket namespace but I have not used it so I don't know how well it works with WinBatch.   Most Framework classes work just fine but there are exceptions.

https://msdn.microsoft.com/en-us/library/system.net.sockets.aspx

Or you could just use Python from a WinBatch script.

[stanl]

The WinSock extender does not support UDP.  You could check out the .Net socket namespace but I have not used it so I don't know how well it works with WinBatch.   Most Framework classes work just fine but there are exceptions.

https://msdn.microsoft.com/en-us/library/system.net.sockets.aspx

Or you just use Python from a WinBatch script.

A simple 'bridge' to the .NET solution, if you want to investigate that route, might be testing in Powershell. The url below and the earlier article it references do a good job at outlining the scope of working with UDP. If you test and find the PS code works, translating to the WB CLR should not be too difficult [ I say that tongue in cheek as dummies like me try to and Tony responds with working code generally for increasing WB capabilities].

https://learn-powershell.net/2011/10/23/querying-udp-ports-with-powershell-part-2/

[IJRobson]

Thanks for the confirmation that the WinBatch Extender does not support UDP.

I have a solution using the Python Script method but the Redirect of the Python Script output is being buffered before I can read it.  So although the Python Script has displayed the UDP Packet data it is not being redirected to WinBatch until a large number of packets have arrived.  As the Packet arrive in short bursts with long gaps between the bursts it is taking a very long time (minutes) before any Script Output is read by WinBatch.  I really need a way to reduce this buffering.   Is there any way to reduce the amount of PIPE Data that has to be received before that Output is returned?

I will take a look at the .NET method but I think it is likely to suffer from the same problem as MSWinSock which does support UDP Packets but has no FIFO or Buffering on Packets thus if you don't services incoming Packets quickly enough then they are overwritten by newer Packets.  My Data consists of lots of 3 & 4 Byte Packets sent one after another thus very easy to loose packets.

Thanks

[td]

I would not make any assumptions about what the system.net.sockets does or does not support.  This is because there have been more than a few instances where the dotNet Framework has a more complete implementation of a Windows service than COM Automation.  The dotNet implementation of RegEx being but one example.

[ChuckC]

Just going to toss this out there for consideration when it comes to concerns about UDP and packet loss...  By design, UDP is lossy, whereas TCP is made to be lossless.  Any UDP listener application that is not capable of processing received UDP datagrams quickly enough will result in lost data.  This may well mean that WinBatch isn't the best choice if the datagram transmission rate is too high for a single threaded application to handle.  When looking at various .NET or COM based UDP listener implementations that can be consumed by WinBatch, look for ones that actually implement a separate listener thread and queuing system for received data so that your script only has to process the datagrams that have been received, but doesn't have to be responsible for the actual "listening" work that receives the datagrams from the IP stack.

[td]

The  System.Net.Sockets dotNet namespace provides a UpdClient class.  The rub is that it requires a delegate to perform asynchronous operations and WinBatch does not support delegates directly.  The workaround is to write a small amount of C# code to act as a delegate and then compile that code inside a WinBatch script.  This is actually easier than it sounds. 

Should add that I have not tried using the UpdClient class so I can't guarantee that the above workaround will work and I do not have an example. But there is nothing in MSFT's documentation that indicates that it won't work.

[IJRobson]

ChuckC
Thanks for the comments on UDP as it raises a larger concern.  My actual requirement for the WinBatch application is to Read UDP Data from multiple Sources concurrently.  So it is not as simple as reading UDP Packets in on just one port there could be say eight separate devices each sending UDP Packets on separate ports and WinBatch needs to collect that Data from each.

TD
Thanks for the information on .NET and UpdClient class that is something for me to investigate further.


I do have the Python Script method working although it does take a long time for the redirected output from the Python Script to be accessible to WinBatch.

This method also provides the ability to run multiple Command Prompts each running a separate Python Script handling a Device / Port.   This leaves WinBatch just starting these Scripts and then reading the redirected Output from the Scripts.  As each new Python Script is running in a separate Command Prompt they just have to handle reading the UDP Packets as they arrive.

It does require a PC powerful enough to run multiple Command Prompts plus WinBatch but it should work.