Re: [Openvpn-devel] Many to one TCP question

[Mike Auty]

Hi,
	I have never found any problems using UDP as the tunnel mechanism over 
the internet.  I was under the impression that UDP packets were less 
likely to be blocked at the firewall than TCP, since historically it has 
been under utilized.  These days with streaming video/media where speed 
is more important than reliability, UDP is really beginning to be used a 
lot and so I would have said the difficulties in using UDP through 
firewalls is equal to using TCP.
	The advantages of using UDP to tunnel data are that it reflects the 
underlying physical layer very well, whereas TCP has reliability 
controls built in.  These monitor the speed of connections, include 
timeouts in case of lag and various other mechanisms to maintain a 
connection.  Unfortunately if you then tunnel TCP on top of TCP, these 
mechanisms can interact poorly and produce very poor results.  At least 
that what I recall reading somewhere (after a quick dig it turns out the 
page was part of the CIPE project which was also based on the tun/tap 
virtual adaptor system, see 
http://sites.inka.de/sites/bigred/devel/tcp-tcp.html).
	Anyway, personally I would always use UDP, I currently have a LAN 
bridged with a many to one UDP openvpn (linux) server, all the various 
openvpn (windows and linux) clients can interact with the LAN clients as 
if they were all on the LAN (and vice versa).  I would definitely 
recommend this for road warrior solutions.  Hope this helps...

Mike  5:)

Re: [Openvpn-devel] Many to one TCP question

[Lonnie Cumberland]

Thanks for replying to my posting on this matter as I am still trying to 
get clear understanding as to the advantages/disadvantages of using 
TCP/UDP protocals.


My guess is that most things are done via TCP over the Internet and I 
seem to remember that there are supposed to be many problems with trying 
to use UDP over the Internet because of firewalls, bridges and the like, 
or something like that.


Also, is it true that you cannot bridge with UDP connections for road 
warriors with Windows (OpenVPN) machines wishing to connect to Linux 
(OpenVPN) machines and servers?


I could be totally off base here, but it UDP protos would work then I 
could go along that route instead for my project which needs to also 
scale to a (potentially maybe) very large number of road wariors.


Cheers,
Lonnie

James Yonan wrote:


Lonnie Cumberland  said:

 


Hello All,

Well, I've been away from the list for a little while and was wondering 
if someone could please bring me up to speed on the development of the 
"Many-to-One" TCP progress?


It is my understanding that in the OpenVPN 2.0 (early) Beta, that UDP 
connections can be established in a many to one TAP/TUN interface, but 
how about the TCP side?
   



TCP support for multiple-clients going through a single tun/tap interface is
probably not going to be here for a while unless someone sponsors the work. 
The problem is that it's difficult to scale, because TCP connections require

one socket per client, while UDP connections can use a single socket to talk
to any number of clients.  Most OSes lack an efficient API for waiting on the
status of a large number of sockets.  The one notable exception is Linux 2.6
which has the epoll API.  Most application developers get around this
limitation by using multiple threads or processes, where each thread/process
waits on a single socket.  But then you have the inefficiency of a large
number of threads/processes and the interprocess communication overhead
entailed by that.

James



 

Re: [Openvpn-devel] Many to one TCP question

[James Yonan]

Lonnie Cumberland  said:

> Hello All,
> 
> Well, I've been away from the list for a little while and was wondering 
> if someone could please bring me up to speed on the development of the 
> "Many-to-One" TCP progress?
> 
> It is my understanding that in the OpenVPN 2.0 (early) Beta, that UDP 
> connections can be established in a many to one TAP/TUN interface, but 
> how about the TCP side?

TCP support for multiple-clients going through a single tun/tap interface is
probably not going to be here for a while unless someone sponsors the work. 
The problem is that it's difficult to scale, because TCP connections require
one socket per client, while UDP connections can use a single socket to talk
to any number of clients.  Most OSes lack an efficient API for waiting on the
status of a large number of sockets.  The one notable exception is Linux 2.6
which has the epoll API.  Most application developers get around this
limitation by using multiple threads or processes, where each thread/process
waits on a single socket.  But then you have the inefficiency of a large
number of threads/processes and the interprocess communication overhead
entailed by that.

James