[ENet-discuss] File transfers w/ e-net

Mike Diehl mdiehl at diehlnet.com
Thu May 13 13:42:03 PDT 2010


OK, I'm convinced.  I was hoping that much of the heartache involved in 
reliable file transmission was already dealt with by e-net's reliable packet 
transmission mechanism.  OK.

So, I need to find a decent http client library that I can call from C.  This 
approach does open up the possiblity of downloading content from a DIFFERENT 
server, perhaps one I don't even have to own/manage.  I'll bite the bullet.

Any library suggestions?

Mike.
On Thursday 13 May 2010 12:53:54 pm ryan.rogers at frontiernet.net wrote:
> Hi folks,
>
> Yep, under ideal conditions, UDP can be great at file transfers.  For our
> render farm distribution here at work, I've written a file patcher which
> syncs directories across the network at uber-speeds by leveraging large
> frame transfers, and of course infrequent OOO's and virtually no drops. 
> It's about 35% faster than copying a file over SMB share!!!  When
> multicasting, it can be orders of magnitudes faster, as I can update 50
> render nodes with one transfer of the data over the network.
>
> However, this is on a high speed reliable LAN with fantastic switches, and
> I knew that when I started.
>
> But what about less than ideal conditions, like the Internet, and servers
> that are starting to approach maximum thresholds?
>
> One area you will run into problems is the lack of throttling due to packet
> loss under server or network duress.  The hosts can end up choking
> themsleves due to lack of ack's and multiple resends; a small problem ends
> up being amplified into a big one due to the protocol being dumb.  TCP has
> a fairly sophisticated implementation to provide this stream control.  If
> you roll your own on UDP, it's not-trivial to get one that works well under
> most scenarios, and when you are all said and done, you've essentially
> re-implemented a good bit of TCP, and it will have similar (or..egads!)
> worse performance.
>
> And if that is the eventual outcome, why did you bother to begin with?I
> don't like reinventing the wheel. ;-)
>
> My advice is if I've got stream to copy over the Internet from a single
> source, chances are TCP or one of the app protocols built upon it (HTTP,
> FTP, etc) is the right choice.
>
> Rhino
>
> ----- Original Message -----
> From: "Kenneth Bull" <llubnek at gmail.com>
> To: "Discussion of the ENet library" <enet-discuss at cubik.org>
> Sent: Thursday, May 13, 2010 1:29:20 PM
> Subject: Re: [ENet-discuss] File transfers w/ e-net
>
> On 12 May 2010 19:46, Chris Jurney <jurney at gmail.com> wrote:
> > Agreed.  You might look for something better suitted to transferring
> > files than eNet like the File Transfer Protocol.  TCP has had a lot of
> > effort poured into it to solve exactly this sort of problem.
>
> Actually, using UDP for file transfers could give you a bit of a speed
> boost.  If you send the file offset with each packet, the client could
> assemble the file out of order and request missing blocks as needed.
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss



-- 

Take care and have fun,
Mike Diehl.


More information about the ENet-discuss mailing list