Just use tcp sockets... enet even provides a low level api for raw socket access.... There is no reason to use http unless you really need it.
On Thu, May 13, 2010 at 4:42 PM, Mike Diehl <[email protected]> wrote: > 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 > _______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
