Multiplexing function suggestion about udpspeeder HOT 8 OPEN

especially when some online games send UDP packets with inappropriate socket strategy that it creates new socket to send every UDP packet

UDPspeeder increases number of packets, it shouldn't increase num of (unique) 5 tuples even if the inappropriate game creates new socket on every packet (at least from my understanding)

I think maybe a UDP multiplexer option may solve this problem. I do understand this will cost more traffic to record real socket info in UDP message part and reduce the efficient body length under same MTU, but it may be really useful in some cases

if multiplexer does work for you, you can pipe UDPspeeder traffic through some other tunnels which supports multiplexer by themselves. For example:
UDPspeeder----->udp2raw---------------(internet)----------------->udp2raw------>UDPspeeder
UDPspeeder----->wireguard--------------(internet)----------------->wireguard------->UDPspeeder.

from udpspeeder.

or maybe:

wireguard----->UDPspeeder------------------(internet)------------->UDPspeeder------>wireguard

then there will be only a single 5-tuple exposed to both UDPspeeder and the ISP

from udpspeeder.

Thank you for your reply.

I have recently tried udp2raw. But it introduces extra 10ms latency during every half loop even I have closed the encryption. It is unbearable for some of FPS players.

I haven't tried wireguard. I will try it later and feedback. Thank you for your advice. :)

from udpspeeder.

no udp2raw shouldn't add that much latency.
when I hear something like 10ms, usually it's the latency glitch by some ISP load balancing strategy (or other ISP stuffs). (not sure if IPLC makes a difference)

a properly written c++ program shouldn't add that much latency

If I remember correcly when I do loop test locally it adds only a few ms (a few should be < 2)

from udpspeeder.

You are right. I didn't consider about ISP tcp latency. I suddenly have an idea. If I use raw-mode UDP in udp2raw, will it multiplex all traffic into a same 5-tuple as what it does in tcp mode？

from udpspeeder.

If I use raw-mode UDP in udp2raw, will it multiplex all traffic into a same 5-tuple as what it does in tcp mode？

yes, all modes of udp2raw have built-in multiplexer

but I suggest you to use this method (as least try it as the baseline for troubleshooting):
wireguard----->UDPspeeder------------------(internet)------------->UDPspeeder------>wireguard
it's likely to have least problems

especially when some online games send UDP packets with inappropriate socket strategy that it creates new socket to send every UDP packet

since when a network program malbehaves like this, there might be other weird problems you are not aware of
but a tun/VPN based solution can filter out most of those possible weird problems.

from udpspeeder.

If I use raw-mode UDP in udp2raw, will it multiplex all traffic into a same 5-tuple as what it does in tcp mode？

yes, all modes of udp2raw have built-in multiplexer

but I suggest you to use this method (as least try it as the baseline for troubleshooting): wireguard----->UDPspeeder------------------(internet)------------->UDPspeeder------>wireguard it's likely to have least problems

especially when some online games send UDP packets with inappropriate socket strategy that it creates new socket to send every UDP packet

since when a network program malbehaves like this, there might be other weird problems you are not aware of but a tun/VPN based solution can filter out most of those possible weird problems.

I haven't considered about the malbehaviors of popular public softwares until I saw hundreds of established udp sessions created by a single process. I was shocked as well. Maybe they only launched some basic test on the network part of their games without any further optimization.

from udpspeeder.

First, Wangyu, appreciate your work. Thanks.

On the multiplexing/demultiplexing topic, I hope the following function could be added. Still it is a single flow from application perspective.

• create multiple tunnels - different ip:port combination, or simply different port in 2.2.2.2
  e.g. 3 tunnels
  1.1.1.1:1024 - 2.2.2.2:1111
  1.1.1.1:1025 - 2.2.2.2:7778
  1.1.1.1:5101 - 2.2.2.2:9999

It avoids blocking traffic by inspecting single destination port

• The better case is to allow different destination IP finally terminated at the same host. The host has .2, .3 and .4 IP.
  1.1.1.1:1024 - 2.2.2.2:1111
  1.1.1.1:1025 - 2.2.2.3:7778
  1.1.1.1:5101 - 2.2.2.4:9999

Remember the frequency hopping theory...I would like to see that.

from udpspeeder.