Forums Feature Suggestions DCC SEND is horribly out of date

The DCC SEND command has two things that make it out of date:
1) Is that it still uses IPv4 encoding for the IP address. There is very little documentation on it, it is out of date, and causes problems with other IRC clients. It should at the very least
2) The command itself is out-of-date. Instead, XMIT should be used. To maintain backwards compatibility, SEND can still be enabled but right now XMIT doesn't even seem to be supported.

Does DCC SEND work? Yes.
Does mIRC need DCC XMIT right now? No.

Improvement is always good, but there's really no NEED for this IMO =\

Regards,

SEND works yes. But what if some one using a newer IRC program that uses XMIT wants to send an mIRC user a file? They can't, unless they download an older IRC client or use another method. I just think mIRC should support both. It wouldn't be that hard, the only real difference between XMIT and SEND is that XMIT is faster because it doesn't require packet acknowledgement (which is redundent in SEND because TCP/IP takes care of that at a lower level).

Why not add support for XMIT? It should only take a little while to impliment and it would create compatability with a wider range of clients.

As far as my first comment, I meant to say 32-bit unsigned int network byte order IPv4 addresses (as opposed to 32-bit dotted notation IPv4 addresses). I just wanted to clarify that.

Two points:

- If the majority of people (or a large proportion of those that send files via IRC) use mIRC, then finding an XMIT only person isn't going to be too Easy.
- I don't think Khaled really wants mIRC to be known for being the best file swapping client

There is documentation on DCC, under the CTCP specification:
http://www.irchelp.org/irchelp/rfc/ctcpspec.html

Specifically, DCC <type> <argument> <address> <port> <size>

In case of DCC SEND, it would be:
DCC SEND <filename> <address> <port> <size>.

The command isn't out of date. By your argument, IRC would be obsolete because RFC 1459 was written in 1993.

If your client doesn't support DCC SEND, then that's your problem. DCC SEND is a "de facto" standard, and if the client chose not to support that, then that's something that you should take up with their coder.

i think xmit support is a great idea, and i dont quite get the point of you other people. just because the majority of users are using mIRC, it shouldnt be supported? thats quite stupid imo. you could still use send if you want to, xmit wouldnt break backwards compatibility at all. sometimes its just time to move on! also, if khaled doesnt want mirc to be a file-sharing tool, why did he include dcc at all? or even the fserv? if everyone would think like you, we'd all be chatting with telnet

telnet chatting rulz ;b
like a biiiig exersise that you have already solved with your grandma and now you want to beat alone ;b

Yeah, DCC SEND is really outdated and stupid. I can't see why people are trying to hold on to something like that. Do you want file transfers to be slower than they have to be? NO! The world goes forward and so does IRC.
I really do think that mIRC should support XMIT!!

mIRC already has one perfectly acceptable method of transferring files, which is used by every IRC client that I've used. Why waste more effort when the functionality to send files already exists?

> if khaled doesnt want mirc to be a file-sharing tool, why did > he include dcc at all? or even the fserv?

There are valid reasons to send files over IRC. However of the past 10 odd years people have found other, more illegal uses for it.

This is a case of marginal analysis. Should we ADD EXTRA features to an existing set? Is the marginal benefit worth it? (Ever did Economics??). There is a benefit in Khaled keeping the existing DCC features and there is a benefit in not improving those features. He's found the right level of functionality for DCC.

Remove DCC and people will go to other clients or older mIRC versions. Improve DCC and he'll most likely be getting mIRC a rep. worse than Kazaa.

> Do you want file transfers to be slower than they have to
> be? NO! The world goes forward and so does IRC.
> I really do think that mIRC should support XMIT!!

Perhaps it's an advantage. People who download warez and pr0n using IRC channels are encouraged to go elsewhere as it's too slow on IRC. Meanwhile those who just want to send a file to a mate e.g. a personal picture, funny wav, etc... will still be happy as the speed of a one-off transfer really is quite irrelevant and unimportant.

Sounds like a win-win to me.

>mIRC already has one perfectly acceptable method of transferring files, which is used by every IRC client that I've used. Why waste more effort when the functionality to send files already exists?

Duh, DCC SEND is not perfect! I think it's the most stupid protocol there is.

> Improve DCC and he'll most likely be getting mIRC a rep. worse than Kazaa.

Yeah, sure. Kazaa is only made for file swapping - mIRC is not. So, i can't see how it could get a wrose rep. than Kazaa. It isn't even the same type of software.
And the best thing with IRC is that you can easily stay away from things you don't want to take part of. You could easily stay away from this too. Or are you afraid that the feds are going to take mIRC away from you? It's never going to happen. They can't make every app, that can send files, illegal. Should file transfers in your browser/ftp client also be slower than they have to be, to stop people from sharing warez and stuff? Where is the logic?

> Duh, DCC SEND is not perfect! I think it's the most stupid
> protocol there is.

I said it was a perfectly acceptable method. Not a perfect method.

> Yeah, sure. Kazaa is only made for file swapping - mIRC is
> not. So, i can't see how it could get a wrose rep. than
> Kazaa. It isn't even the same type of software.

Exactly. mIRC currently is not a real file swapping client. Doing things like adding XMIT, limiting bandwidth functions, etc... to mIRC makes it more and more like a file swapping client. And so then mIRC's rep for being used for file swapping will grow, and get worse.

The fact that it is not the same type of software is irrelevant. It is what people are trying to make mIRC become which is relevant. It should also be noted that both programs share similar functionality in certain areas.


> And the best thing with IRC is that you can easily stay
> away from things you don't want to take part of.

And by your own logic, the best thing with mIRC not having a monopoly on IRC clients is your ability to go use a client of your own choice. You can easily stay away from mIRC if you don't like the way it's heading.

> Should file transfers in your browser/ftp client also be
> slower than they have to be, to stop people from sharing
> warez and stuff? Where is the logic?

An FTP client is designed for the transfer of files. A web browser is designed for the transer of files. The primary purpose of those two types of clients is the transfer of files. The primary purpose of an IRC client is not.

>And by your own logic, the best thing with mIRC not having
>a monopoly on IRC clients is your ability to go use a client of
>your own choice. You can easily stay away from mIRC if
>you don't like the way it's heading.

The way it's heading? It seems like you want it to stand still.
And the reason for it beeing used in an illegal way isn't reason enough for not adding it. Why don't you tell Khaled to remove DCC SEND all togheter? Listening to you, it would be the only way to go. So it doesn't get bad reputation among people that doesn't now anything anyway.

This has been said thousand of times - The chance of people using a feature in a "bad" way isn't a reason enough for not adding it. Why should the "bad" users disallow us other to using something that could help us? It won't hurt you or mIRC!

At last, mIRC have alot of useless features, that are not needed for irc, a better DCC SEND isn't one of them.

>The way it's heading? It seems like you want it to stand still.

In certain areas, yes. This is one of them.

>And the reason for it beeing used in an illegal way isn't
>reason enough for not adding it. Why don't you tell Khaled to
>remove DCC SEND all togheter? Listening to you, it would be
>the only way to go. So it doesn't get bad reputation among
>people that doesn't now anything anyway.

As I explained, this is a marginal thing. We've already got DCC SEND. Removing it won't help things - people will just use an older mIRC. Adding a new sending functionality will encourage more illegal downloads that it will in other areas. The only reason that people seem to be using for XMIT is that it's more efficient. What are the benefits of this efficiency, compared to the costs? Cost: lots of illegal downloads, benefit: slightly faster transfer speed. You do the math.

>This has been said thousand of times - The chance of
> people using a feature in a "bad" way isn't a reason
> enough for not adding it. Why should the "bad" users
> disallow us other to using something that could help us?

Because the feature has more bad than good. Fast file sending over IRC isn't really important, as I've said. There are programs specifically designed for file transfer. Next thing you know you'll be asking for gzip compression before sending.

> It won't hurt you or mIRC!

It will hurt mIRC's reputation.

> At last, mIRC have alot of useless features, that are not
> needed for irc, a better DCC SEND isn't one of them.

I've come across this argument MANY times and it's completely invalid. Just because useless features were put in the past does NOT mean that useless features should continue to be put in to mIRC. Ever heard of the expression 'to learn from your mistakes?'.

Here's a thought:

Why don't you just script it?

well I'm +1 for this feature

Just include it for the sack of support, and default to using SENDs all the time, unless another client requests the new protocal...

How can a new protocal ever get common place if one of the major IRC Clients doesn't even support it...

bramp

For some people I want to make clear that I did not intend to state that DCC SEND should be eliminated, just that DCC XMIT should be added (even if it only allows recieving and not sending the command).
As far as the RFC goes. Yes, XMIT is not specified in the origional RFC. But that is very old now. Might I also add that file resumming is also not in there. File resuming isn't even standard, it is a de facto standard set by mIRC and a few others. Resume isn't in the origional documents, should we get rid of that?

I have yet to see significant a reason not to support it. Other than the fact that some people are afraid of change. Of course you should keep DCC SEND but there is no reason not to add support for DCC XMIT.
Why not?

I'll tell you why... faster and more streamline transmitions and complience with cutting edge clients. Stop adding new features to the protocal and I guarentee you that in a few years mIRC will no longer be the leading IRC client. Even if I am wrong, why risk it?

> For some people I want to make clear that I did not intend to
> state that DCC SEND should be eliminated, just that DCC
> XMIT should be added (even if it only allows recieving and
> not sending the command).

Why not just write a script for it if you want it soo badly?

> Yes, XMIT is not specified in the origional RFC. But that
> is very old now

Another poster pointed out that the age of an RFC is irrelevant. Your point is invalid.

> I have yet to see significant a reason not to support it.

Waste of time implementing something for which we already have a satisfactory implementation for. Why reinvent the wheel?

> I'll tell you why... faster and more streamline transmitions
> and complience with cutting edge clients.

Is that speed increase that big? How many minutes a day will it save the average IRC user? Compare that to how many minutes a day it would save the average leecher. I think you'll find this to be far more beneficial to the leecher than your average IRC Joe.

mIRC isn't a file server, kazaa is, ftp servers are, www servers are.

> Stop adding new
> features to the protocal and I guarentee you that in a few
> years mIRC will no longer be the leading IRC client.

What protocol are you referring to? IRC? DCC? I honestly cannot see people changing IRC clients just because the file sending is a little slower. If someone was really determined, they would just make a script.

> Even if I
> am wrong, why risk it?

Because it's a risk worth taking.

I'm sure Khaled has better things to do than make mIRC send pirated files faster. Consider the following scenario:

- Spend time to internationalise mIRC and thus increase the spread of mIRCs userbase substantially from the increased use by non-english speakers. This substantial increase will most likely result in increased registrations, which is food on the plate.

- Spend time to make files send faster so people can get the latest copy of LOTR and Harry Potter before it comes out in their local cinema. No substantial increase in user base, no substantial increase in registrations (hey, they don't pay for the warez, why would they pay for mIRC??)... no extra food on the plate.

The choice seems obvious.

Once again, if people so desperately want a faster way to send files, script the support. If people truely feel that the extra speed is worthwhile, they'll download it. No problem. Meanwhile Khaled gets to program some more interesting features.

I agree with Pasmal. mIRC is primarily for chatting. If mIRC was to implement this, where next? Multi-user downloads? Sorry, but I think you should go to Kazaa if you want filesharing on that level. That's what it's there for. And really, your transfer speed is only going to be as fast as the slowest person's connection anyway. And tronicer, just because your idea is knocked back, or people don't agree with it, doesn't mean to say that mIRC isn't moving forward.