felipejfc / udpx

A Fast UDP Proxy written in Golang

UDPX

A Super Fast UDP Proxy that works as a NAT (has support to multiple clients) written in Golang.

About

Features

• Super Fast
• Can Handle Multiple Clients
• Act as a NAT
• Dynamic upstreams
• Multiple upstreams

Dependencies

• GO 1.7

Compiling

make build

Usage

$ ./bin/udpx --help
A fast UDP proxy that support multiple clients and dynamic upstreams

Usage:
  udpx [command]

Available Commands:
  start       starts UDP proxy
  version     Print the version number of UDPX

Use "udpx [command] --help" for more information about a command.

TODO

• Add config
• Add command
• Add tests infrastructure
• Travis CI and Code Coverage
• Support to multiple upstreams
• Dynamically resolve upstreams
• Dynamically add proxies
• Dynamically remove proxies
• Resolve new upstream addr if it changes
• Make timeout logic faster by making less updates
• Zap has a leak, maybe use another logger
• Dynamically added proxies must be shared my multiple udpx instances
• Can persist upstreams
• Print statistics of messages sent and clients active /sec
• Persist proxy state between reboots?
• Docs
• Example
• Performance tests
• Add more tests
• Limit clients?
• Docker

udpx's Issues

bufferPool put() should be re-sliced to full BufferSize

Hi,

We've noticed the following issue:

the bufferPool appears to run out of space and during a series of packets, at points the only space remaining in the pool is the size of the previous packet. In this situation if the next packet is larger, an error will occur: "A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram into was smaller than the datagram itself."

This issue occurs even with a large bufferSize (8192 bytes) and small packet size (~800 bytes)

Our test case:

Send 10 packets at 803 bytes size
Send 10 packets at 802 bytes size
Send 10 packets at 805 bytes size (the errors will occur here, some packets may get thru, but not all of them)

This same pattern will reproduce the error, even at smaller number of packets. We see the error consistently in the middle of a packet stream where the next packet is larger than the last.

We modified the code to just write a new buffer for each packet, and the issue seems to be resolved, so it appears to possibly be related to the sync pool

Debug logging doesn't work

When using -d or -debug I don't see the client connections being logged to STDOUT. Any help appreciated!

Possible to do a tcp combination?

Automatically detecting tcp etc for tcp
UDS too but optional

Feature Request: Relay support

Could this tool be used as a UDP relay? I.e. where packets destined to the inbound port are forwarded to more than one upstream?

Thanks,
Damian.

Can be used with a MMOFPS game ?

Hey dude, how are u ?

Well, i'm developing a private server of Sudden Attack, an old game distributed by Nexon, and in Brazil is not available anymore, so we decided to open our private server, but the game room run in P2P.

My question is, i can use this program as a NAT server ? To allow conection between the players ?

Used in CoreDNS

fyi: I'm using your code in coredns/coredns#1131

reworked it a bit to support tcp as well and do more things to allow for DNS, so it's slower.

Found few other issues as well. p.closed is not protected by a mutex and hence not concurrent safe.