Hi All,
Is there any method available to forward packets received on one UDP socket port to other UDP socket port. I have created two sockets one for app and one for driver for different purposes. And i need to forward the packets received on driver port to app port. Any windows API or setting is available to accomplish this?
Thanks,
I found an option to reuse the same port which is already assigned to the socket created by the application.
Using SO_REUSEADDR
The SO_REUSEADDR socket option allows a socket to forcibly bind to a port in use by another socket. The second socket calls setsockopt with the optname parameter set to SO_REUSEADDR and the optval parameter set to a boolean value of TRUE before calling bind on the same port as the original socket.
Ref: https://docs.microsoft.com/en-us/windows/win32/winsock/using-so-reuseaddr-and-so-exclusiveaddruse
When i call the PfnWskControlSocket() to set SO_REUSEADDR, the call succeeded. But for some reason the WskBind is still failing when i mention the same port which is assigned to the application. WskBind returing STATUS_SHARING_VIOLATION.
Any input to debug this issue…
SO_REUSEADDR is unlikly to be helpful for your problem. you want to forward packets from one socket to another (so i understand) but this flag allows opening multiple handles on the same address and port?
Yes i want share one port between two sockets. One socket at the driver level will transfer packets to the server and the other socket at the app level will receive the packets from the server.
It has been a long time since I used this feature, but i think both sockets need this set so that the OS knows they plan to cooperate.
you would need very special circumstances for this to be a good idea though. it would be much simpler to do all of the sending and recieving in either UM or KM and have an IOCTL inteface between the two to pass the data meant for the other component. For example, one socket in KM. the KM code that needs to send uses it directly. the UM code that wants to recieve instead of calling recv etc., calls ReadFile on your driver. your driver then reads from the socket. if performance is a question, make sure to use overlapped IO and pend several requests. if you are worried about UM / KM transitions, there will be the same number with this design as there would have been with calling winsock in UM. the only difference will be a few extra stack frames where your driver sits
in UM, the thread pool APIs can make this quite simple especially as this is UDP and each packet is stateless
I will eventually move the recv part also to kernel side. Before moving the recv part i want to check the performance improvement if doing send operation at the kernel level is better or not.
I saw some doc in MSDN that explains grouping socket to multicast group. So that all the sockets in that group will receive packets.
“If two sockets are bound to the same interface and port and are members of the same multicast group, data will be delivered to both sockets, rather than an arbitrarily chosen one.”
I am seeing API and example how to add a socket at the user level using “setsocketopt” but couldn’t find relevant API at the kernel level.
https://www.winsocketdotnetworkprogramming.com/winsock2programming/winsock2advancedmulticast9a.html
what sort of performance improvement are you expecting by doing the sending from KM? avoidance of a couple of context switches? Properly done IOCP and overlapped multi-packet send and dequeue calls mitigate this extremely well
GetQueuedCompletionStatusEx can get multiple completions in a single context switch
https://docs.microsoft.com/en-us/windows/win32/fileio/getqueuedcompletionstatusex-func
and WSASend can send multiple packets in a single context switch
https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-wsasend
and the best part about this behaviour is that is becomes more efficient the more heavily loaded your system becomes. Automatically adjusting from latency to throughput