suggestion.

[Joshua Coombs]

As a "network engineer", you should know that the
internet in general doesn't guarantee in-order
packet delivery. So any application that doesn't
handle it is simply unreliable on the internet.
If an application requires in-order delivery, you
can direct the traffic to use a single link. But
you can't guarantee what happens once its out of
your network. So without a transport layer your
application is just a crapshoot.
You have all sorts of load-balancing going on
throughout the internet, and almost none of it
guarantees in-order delivery. So if you sabotage
your own link thinking that you're going to make
something work, then you just don't understand
the big picture.
Danial
I'm fully aware of that.  Inside my network, I'm performing VoIP, and 
at some points in my network, there are multiple point to point paths. 
Rather than clamp VoIP to one of those paths, and have to correct for 
it when it breaks, I rather just use a feature of one of my transport 
options to make things behave the way I need them to.  I don't 
consider this sabotage, rather (repeat warning) using the right tool 
for the job.  CPU and Memory are cheap and managable, links where I 
need them are expensive, and take time to push through from order to 
carrying data.

I like options and choice, please don't take that away just because 
you only prefer one methodology.

My vote: If DFly can support both, great.  If not, support whichever 
provides the most functionality and flexability.

Joshua Coombs