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 [email protected] 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" <[email protected]> > To: "Discussion of the ENet library" <[email protected]> > 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 <[email protected]> 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 > [email protected] > http://lists.cubik.org/mailman/listinfo/enet-discuss > _______________________________________________ > ENet-discuss mailing list > [email protected] > http://lists.cubik.org/mailman/listinfo/enet-discuss -- Take care and have fun, Mike Diehl. _______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
