[dcc2] Question about the necessity of multi file sends

[Tom McAlee]

One thing a client could do with multi sends that it could not do with a
.zip file (and a single, simple dcc request) is decline individual files
based on file type or some other criteria.  Perhaps I want to accept files 2
and 4 but want to skip 1 and 3?  A multi send protocol can be defined to
allow that; zipping everything up and sending it along does not, and the dcc
request received by the client doesn't even indicate what kind of files are
inside.

Since it was you (codemastr) who was talking last week about protecting the
users, how about a .zip file that contains:

PictureA.jpg
PictureB.jpg.exe
PictureC.jpg

(iow, the oldest trick in the book to get some less computer-literate to
launch a file)

Sent as a multi send using a protocol that allows the client to see the
names of the files before they are transferred, PictureB.jpg.exe would be
rejected by any client that doesn't allow unsafe files (like many clients do
my default).  And, the client may understandably decide to decline all sends
from a person who tried to send such a thing.

Even if the client itself unpacked a .zip file and decided which ones to
throw out... well, you've still managed to pass them along and there's no
telling what might happen to the files while they exist in a temporary
directory on the receiving client's machine.

There you have it - at least one nice use of multi send for real IRCers (as
opposed to warez traders).

----- Original Message ----- 
From: <codemstr at ptdprolog.net>
To: <dcc2 at dcc2.org>
Sent: Monday, May 10, 2004 12:55 AM
Subject: [dcc2] Question about the necessity of multi file sends


> As I'm sure everyone here knows, I've been pretty much against the idea of
> multi sends from day one. The reason I'm making this post is, because the
> more I read about users comments on DCC2, the more I realize, I'm not the
> only one against it. It seems almost everyone sees this as promoting one
> thing, and only one thing, more warez.
>
> What I'd like to know is, what exactly does the multi send feature do,
that
> any archiving tool (zip tar gzip etc) can't do?
>
> There is only one thing I can come up with. And that is easily dynamically
> generate a multi file send. What I mean is, say I want to download some
> warez. I want to download 5 seperate movies. Most likely, the guy I'm
> downloading from does not have those 5 movies in a single zip file (not
> everyone is going to want the same 5 I do), and it's doubtful he has a
> program that will auto package them into a .zip for me (this could cause
> tremendous temporary disk space usage depending on # of files and users).
So
> in that instance, I need to do 5 seperate sends.
>
> Multi sends changes this. Now, the sender can easily package all 5 movies
> into a single send. He'd just have to use whatever scripting command his
IRC
> client provides. Maybe:
>
> multi = new MultiFile();
> multi.Add("movie1.avi");
> multi.Add("movie2.avi");
> ..
> multi.Add("movie5.avi");
> DCC.MultiSend("codemastr", multi);
>
> And *poof* there are all my files in a single transfer.
>
> That is the only thing I see multi transfers doing that a zip file can
not.
> And, that is not something I personally want to see added to IRC as all
that
> will promote is more warez. If your friend is sending you 50 photos, he
can
> zip them up, only warez distributers can't.
>
> Basically, I'm just wondering, can multi sends be justified? I'm sure
there
> will be many client developers that refuse to implement it. I mean most
> IRCers do not want to see IRC become p2p so users will fight it. Looking
on
> the mIRC forums, out of 6 people who posted comments about DCC2, 4 said
they
> think the new file send features will add more warez, 1 said he supports
it
> (but his reasons would be solved by zip) and one was undecided. It's not a
> large survey of people, but that certainly is not a majority in favor. On
IRC-
> junkie, I see 3 more people who said to just use zip, and no one who
really
> came out and said they want multi file sends (that's 3 excluding myself).
> And as I already said, UnrealIRCd will include an option to let admins
block
> it; I put a little poll on our forums, only 13 people responded, but only
3
> out of 13 people were against having a way to disable it, so in my book
> enough users support having such an option. When searching google for
DCC2, I
> really seems that most people either don't want multi sends, or have no
> opinion. There seem to be very few people who actually want such a thing
on
> IRC, and they want it for reasons that zip files already address. So if
users
> don't want it, and think it will be generally bad for IRC, and it provides
no
> real functionality addition, why add it?
>
> It just seems like every reason that has been given to justify multi sends
> can just as easily be done with a zip file. It supports directory
structures,
> it lets you send all files in one transfer, etc. I just don't see the
reason
> to add such a complex feature to DCC if no one can come up with a real
reason
> why it is needed.
>
> If multi file sends were really such a huge issue, we'd already have them
in
> the form of zipped files. An IRC client would let you select a group of
files
> from a list, auto add them to a .zip (libraries exist that handle all of
this
> for you) and send that zip file rather than the individual selected files.
> Then you'd have support for multiple files and directory trees. However,
to
> my knowledge, no clients support this. So if no one has really seen the
need
> to support it, and most people don't want to see it supported, why bother?
>
> In my mind, the purpose of the RFC process is not to turn DCC into what
*we*
> want it to be, it's to turn it into what the overall IRC community wants
it
> to be (in a realistic manner). So far, I've yet to see an outcry from IRC
> users to support multi file sends, only an outcry not to support it.
>
> Comments?
>
> -- codemastr
> _______________________________________________
> dcc2 mailing list
> dcc2 at dcc2.org
> http://six.pairlist.net/mailman/listinfo/dcc2
>