Doesn't work with HTTP protocol

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Launch udptunnel client "udptunnel.exe -c 127.0.0.1 8888
IP_UDPTUNNEL_SERVER 12345 127.0.0.1 80" . And the udptunnel server
./udptunnel -s 12345 (this server MUST have a httpd process running)
2. Open the browser and enter the url http://127.0.0.1:8888 : nothing
displayed.

What is the expected output? What do you see instead?
The expected output should be the web page. But here we see nothing

What version of the product are you using? On what operating system?
Latest version, r9

Please provide any additional information below.
This problem occurred due to the http protocol that has a multiple small
TCP request simultaneously and it seems that your program doesn't like that.
Thank a lot for providing an amazing program. ALl the best 

Original issue reported on code.google.com by RTA.t...@gmail.com on 28 Oct 2009 at 11:20

[GoogleCodeExporter]

I added a branch in branches/udptunnel-proto2 as a quick fix for this, where the
client side generates the session IDs, instead of the server. I'll try to 
figure out
a way to keep the ID generation on the server side without the connection 
requests
getting mixed up.

Original comment by dmeek...@gmail.com on 31 Oct 2009 at 8:20

[GoogleCodeExporter]

Turns out the problem was actually a bug. It should be fixed now in revision 11.

Original comment by dmeek...@gmail.com on 3 Nov 2009 at 11:25

[GoogleCodeExporter]

It work with http but it have 100% CPU usage problem. 

Original comment by phyo.arkarlwin on 6 Nov 2009 at 9:43

[GoogleCodeExporter]

That's because TCP data is ready to be read but the connection is still waiting 
on a
response from the server or client, so the select() call keeps returning 
immediately
but I don't have it call read() yet and just leave the data in the system 
buffer.

In line 266 of udpclient.c and line 203 of udpserver.c, if you change the "#if 
0" to
"#if 1" and recompile, then it will add a millisecond delay between calls to 
select()
and not take up all the CPU time.

Original comment by dmeek...@gmail.com on 6 Nov 2009 at 10:01

[GoogleCodeExporter]

Hmm has this been resolved? I can see this being a major use for this software, 
expecially for reducing delays (from Round Trips) in intercontinental proxying.

Original comment by mat...@gmail.com on 9 Feb 2011 at 7:31

[GoogleCodeExporter]

Not yet. I think I'll just have to read from the socket when it's ready and 
save the data in a queue until it's ready to be sent instead of leaving it in 
the system buffer.

Original comment by dmeek...@gmail.com on 9 Feb 2011 at 2:18

[GoogleCodeExporter]

I did a benchmark of udptunnel with HTTP today FYI

HTTP 1.0 TCP tunnel (nginx reverse proxy) - 110-120ms
SSH tunnel - 140ms per request (+compression +blowfish)
udptunnel - 220ms per request

This was to a small (90kb) file thats is generated very fast, so the majority 
of the overhead is in the inter country transfer (Russia -> Germany -> Russia), 
You would expect UDP to perform the best, so obviously you have some work ahead 
of you before this is ready for prime time.

I recommend using epoll if you can, its a much more efficient way of doing it. 
And providing you can get your head around the code its not any more dificult 
to code and being that you dont need to worry about queueing probably less 
prone to problems.

Original comment by mat...@gmail.com on 9 Feb 2011 at 2:36

[GoogleCodeExporter]

One would think that using UDP would be the fastest for tunneling, but that's 
only if you take advantage of UDP's statelessness. I wrote udptunnel to have 
some reliability, so I created a simple protocol to make sure packets get to 
the destination. It's simple in the fact that it won't send the next chunk of 
data until it gets an acknowledgement from the destination that it received the 
previous data (i.e. only one packet is in transit at a time). TCP was designed 
to try and get the maximum amount of data sent per packet and have multiple 
packets in transit at once. A UDP tunnel program could reimplement TCP to send 
as much data as it can at once and still be reliable, but then the entire 
protocol is being handled again in userspace, counterbalancing the security and 
optimizations the kernel/driver writers tried to achieve. This software was 
designed to get around certain network restrictions, not improve throughput.

That being said, I think it's still worthwhile to write the code this code to 
maintain reasonable throughput and not be a hog on system resources. From what 
I've read, it looks like epoll is definitely better than the old select() 
method, but one of the goals I had when writing udptunnel was to keep it as 
portable as possible, and from what I can find it looks like epoll is only 
implemented in Linux 2.6. I think Windows and Solaris has their own methods for 
effective non-blocking IO, but I'm not really interested in having a bunch of 
different compilation branches in the code. 

I think the best way might be to have a separate thread running for each client 
connection to avoid select() altogether, allowing each thread to hang while 
waiting for IO as needed. However, that requires a little more effort to 
implement than I have available at the time (I'm welcoming of new code if 
anyone wants to take it on). So this brings me back to my original idea of 
having an internal queue hold the data until it's ready to be sent. Yes it is 
more bug-prone, but I think I can do it with minimal problems in the time I 
have available.

Original comment by dmeek...@gmail.com on 10 Feb 2011 at 3:37

[GoogleCodeExporter]

The 100% CPU problem is fixed in revision 17.

Original comment by dmeek...@gmail.com on 21 Mar 2011 at 10:26

• Changed state: Fixed