UDP file transfers (Was: Re: [dcc2] Other comments)

[myndzi]

I've never said UDP was a 'good' solution for file transfers. All
you'd need to implement it, though, is a sequence number and checksum
or hash.

On Mon, 28 Jun 2004 16:55:37 +0100, peter green <plugwash at p10link.net> wrote:
> 
> 
> the other thing about udp is it is needed for some nat traversal
> possibilitys like stun
> 
> -----Original Message-----
> From: dcc2-bounces at dcc2.org [mailto:dcc2-bounces at dcc2.org]On Behalf Of
> Bram Matthys (Syzop)
> Sent: 28 June 2004 16:13
> To: DCC2 Working Group List
> Subject: UDP file transfers (Was: Re: [dcc2] Other comments)
> 
> Jeremy Iverson wrote:
> > If we're talking about allowing UDP at the connection-negotiation
> > level, I think that would be a good thing. Although it is unreliable,
> > there are some applications where this doesn't matter (and hence, why
> > UDP exists).
> 
> I agree... Especially for video/audio etc.
> 
> myndzi wrote:
> > I don't think UDP is needed but it is available so I use it in
> > examples. It wouldn't be hard to number all the UDP packets, assemble
> > them in the file out-of-order, and check a hash or something I
> > suppose. In a file transfer getting the packets in order is NOT a
> > concern. [..]
> 
> I really think *file transfers* over UDP is a bad idea.
> Besides:
> - I doubt it would be actually used
> - I doubt it will be implemented by people
> 
> There are also some "real arguments" (which semi-result in the 2
> points mentioned above).
> 
> When I think of UDP I think about streams/games/..: realtime data
> communication where data may be lost and most of the time (but not all
> the time) should not be retransmitted (think: games - player/object
> positions, realtime video/sound, etc). In this case it's actually better
> than TCP because useless retransmits would only delay the rest of the
> data stream.
> 
> Now for file transfers where obviously the file would need to be
> received 100% correct it makes no sense to use UDP.
> 
> - UDP packets can be send out-of-order, lost, etc, thus it would
>    require _another_ protocol on top of UDP which basically redoes TCP.
>    - This is a lot of work
>    - You are semi-guaranteed to miss things
>    - There's quite a big potential for (security) bugs
> - It really makes more sense to use a stateful protocol here that has
>    been in use and has proven to be functioning fine for over >20 years.
> 
> The only argument I heard pro- UDP filetransfers is that on some networks
> UDP transfers would be possible but not TCP... I doubt this is often the
> case. But furthermore, I don't believe this argument is so enormous more
> valid than all the concerns I just mentioned. Note that it's not always
> "the more options, the better".
> 
> Basically, based on the arguments I heard and thought of, I think
> implementing UDP filetransfers is a waste of time and is guaranteed
> to fail.
> 
> Regards,
> 
>         Syzop.
> 
> PS: Obviously I'm not writing this just to flame people to death,
>      rather I try to share my views and experience here hoping to
>      prevent certain (design) "mistakes". Then again, why would
>      anyone think otherwise? ;)
> 
> _______________________________________________
> dcc2 mailing list
> dcc2 at dcc2.org
> http://six.pairlist.net/mailman/listinfo/dcc2
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.712 / Virus Database: 468 - Release Date: 27/06/2004
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.712 / Virus Database: 468 - Release Date: 27/06/2004
> 
> 
> 
> _______________________________________________
> dcc2 mailing list
> dcc2 at dcc2.org
> http://six.pairlist.net/mailman/listinfo/dcc2
>