Currently the connected socket model is adopted for the performance reasons, that is, UDP packets are dispatched in the kernel.
The connected socket model works if NAT rebinding happens after a connection is created.
Unfortunately, it appeared that some NATs rebind during connection establishment.
There is no workarounds for this kind of NATs with the connected socket model.
So, I'm planning to switch to the unconnected socket model which uses sentTo and recvFrom in the UDP standard way.
Benefits of the unconnected socket model:
The model are friendly with the hasty NATs.
We can support Windows well.
The Haskell code can be simplified.
Servers do not require the BIND capability anymore.
Brawbacks:
Performance gets poorer: packet switching must be done in Haskell code.
Currently the connected socket model is adopted for the performance reasons, that is, UDP packets are dispatched in the kernel. The connected socket model works if NAT rebinding happens after a connection is created. Unfortunately, it appeared that some NATs rebind during connection establishment. There is no workarounds for this kind of NATs with the connected socket model.
So, I'm planning to switch to the unconnected socket model which uses
sentTo
andrecvFrom
in the UDP standard way. Benefits of the unconnected socket model:Brawbacks: