The current patch does exactly that. By default everything's turned off, and you have to enable it using ./configure --enable-udptunnel. Without this option, everything's disabled, with only a single minor exception : the calls in the API are still there (but they don't work, they immediately return an error). But there is *no* change in any of the standard applications as a result of this patch. Nothing at all.
-- Christophe On Wed, May 11, 2011 at 4:59 PM, Perry Halbert <[email protected]> wrote: > What about the regular end user that runs a pre-compiled version. > > They will not be able to turn this off and on unless you provide something > in VBoxManage, and if so should be disabled by default. > > Perry > > > > On 05/11/2011 09:46 AM, Christophe Devriese wrote: > > Well this is unfortunately not possible. Extension packs cannot make use of > the API, they cannot provide support in the UI, nor in the VBoxManage tool. > So if one wants a somewhat usable solution, it can't be done with an > extension pack. > > With this patch you *do* have the choice of having this or not. In fact, > you have to use the --enable-udptunnel configure parameter. So this is on > par with VDE on that point also. > > -- > Christophe > > On Wed, May 11, 2011 at 4:41 PM, Perry Halbert <[email protected]> wrote: > >> Question, >> >> Why not put this in an Extension Pack as an addon instead of changing the >> base code for everyone? >> >> Myself I like the idea of being able to either have this or not. Seems to >> me that is one reason that the Ext. Pack was implemented. What about the >> security of the added UDP protocol such as three-way handshake that is >> missing in UDP used for the validity of the claimed source address. I know >> that all of this seems small but to rush to change the base without >> considering the underlaying issues seems wrong. >> >> If the decision is to include this in the base then there should also be a >> way to disable it built in as well. >> >> Perry >> >> >> >> >> On 05/11/2011 03:02 AM, Nikolay Igotti wrote: >> >> Hello, >> >> Idea of patch is nice, but what I don't understand is how do you >> implement reliable ethernet >> (as carrier collision and packet retransmit in real hardware is performed >> by the NIC) transport over >> potentially unreliable UDP (no guarantees on delivery or frames ordering). >> Cursory look shown no >> code for retransmit or attempts to handle ordering issue in patch. >> >> At least some explanations how do you expect that to work, and tests how >> this whole feature behaves >> in heavily contended networks would be nice. >> >> Nikolay. >> >> On 5/11/11 3:11 AM, Alexey Eromenko wrote: >> >> A letter to community: >> >> UDP Tunnel networking >> --------------------- >> >> UDP tunnel is a great mechanism to interconnect virtual machines >> running on different hosts. It is intended for advanced users. >> >> Technically this is done by encapsulating guest's ethernet frames into >> host's UDP/IP packets, and sending them to the destination. This >> tunnel is a sort of VPN, except that UDP tunnel is not encrypted. >> >> ---------------------------- >> >> This feature will enable GNS3 network simulator to work perfectly >> together with VirtualBox. >> GNS3 allows to build clouds and distributed network topologies in very >> nice graphical way, where you can actually *draw* network topology, >> and interconnect VMs together, even if they run on different physical >> hosts. GNS3 is very user friendly. >> >> So you all are encouraged to test UDP tunnels, and report your findings. >> >> Best wishes, >> >> >> >> _______________________________________________ >> vbox-dev mailing list >> [email protected] >> http://vbox.innotek.de/mailman/listinfo/vbox-dev >> >> >> _______________________________________________ >> vbox-dev mailing list >> [email protected] >> http://vbox.innotek.de/mailman/listinfo/vbox-dev >> >> >
_______________________________________________ vbox-dev mailing list [email protected] http://vbox.innotek.de/mailman/listinfo/vbox-dev
