[dcc2] Question about the necessity of multi file sends

[Tom McAlee]

> Sending multiple files is just easy: open a file dialog, select multiple
files and issue multiple DCC SEND requests. The receiving client is still
able to choose each individual file.

And in every client I've seen, the result is multiple send requests send all
at the same time (not sequentially, where the sending of one file doesn't
begin until the previous is finished).  Thats a major difference.  Sure,
queues can be implemented by scripts, but that lacks standardization.

----- Original Message ----- 
From: "Szymon Stefanek" <pragma at kvirc.net>
To: "DCC2 Working Group List" <dcc2 at dcc2.org>
Sent: Monday, May 10, 2004 11:21 PM
Subject: Re: [dcc2] Question about the necessity of multi file sends


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> /me still thinks that DCC LIST + individual DCC GETS are better for at
least
> the following reasons.
>
> - - It is easier to implement
> Two simplex subprotocols are easier to implement
> than one duplex proto just because the state flow
> is simplier and both subprotocols can share the same
> code (in fact a DCC LIST is a DCC SEND with a dynamically
> created content).
> - - It has a simplier specification
> each subproto can be described in 10 lines of spec
> and does not involve XML or other monsters :)
> - - It doesn't require permanent connections
> Longer connection means higher probability of fault.
> A fault in a multi-file transfer makes it useless.
> - - It is better to understand for an user
> DCC LIST + DCC GET has been already succesfully
> implemented in a non standard way by many clients and bots
> and the result is that *it is used* (now!).
> - - It has higher probability of being a succesfull method
> Since it is *already* working in a non standard way
> there is also less chance that it will be a faulty standard protocol
design.
> - - It is still a secure method and keeps good privacy
> The file list is transferred through DCC LIST and thus through
> a direct client connection. Each DCC GET is issued by specifying
> a file "handle" that is NOT the file name (just because the sender
> offers a list of files in a sort of virtual file system).
>
> The only reason that I think that Multi-Send would be better is in the
case
> where the sender wants to send a really huge list of small files (where
the
> bandwidth of the file transfers is comparable to the bandwidth used by the
> DCC2 handshake). But this is a special case and usually CAN be handled by
> compression methods.
>
> > good points in his response.  Overall, a multi file protocol simplifies
the
> > process of sending multiple files for program authors and/or end users.
>
> Sending multiple files is just easy: open a file dialog, select multiple
files
> and issue multiple DCC SEND requests. The receiving client is still able
to
> choose each individual file.
>
> >  Multi-file sends are
> > already present in most major IM chat clients, and we, as IRC client
> > authors, have already decided that this is a feature many of us want to
add
> > for our users as well.
>
> /me respect this.
> In fact, as long as multi-file is a separate sub-protocol specification,
it
> does not hurt: the clients are not required to support it.
>
>
> - -- 
>
> Szymon Stefanek
>
> - ------------------------------------------------------------------------
------
> - -
> - - Will design spacecraft for food.
> - -
> - ------------------------------------------------------------------------
------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
>
> iD8DBQFAoEbFRu+qkQYW8QERAtY5AKDwIlVFkXXL/9XlwB/mR/jw43laZQCg9noK
> t2FNCM4mbkeq9Lp6auD1oo4=
> =4oOT
> -----END PGP SIGNATURE-----
> _______________________________________________
> dcc2 mailing list
> dcc2 at dcc2.org
> http://six.pairlist.net/mailman/listinfo/dcc2
>
>