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

[Daniel Aquino]

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 <mdiehl at diehlnet.com> 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 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.
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>