/dcc
The Beast upon your shoulder.
I have a request for some info...
I am not on unix, I am running rxirc (very modified), on a IBM Maineframe
and I would like to implement a /dcc function. Does anyone out there
happen to know/have where maybe some specs are, or perhaps have some
C code for /dcc sitting on their directory that they could mail me? Or
if someone has actually implemented a /dcc using REXX and rextcpip would
they like to share? (yeah right who actually programs in REXX around here?)
Well if anyone has any info at all please send it along to me it would be
greatly appreciated... Just send it along to me io9...@maine.maine.edu
no great sig file sorry, all you collectors
Beastie or Tull on IRC
-Mike
Ove Ruben R Olsen
>I am not on unix, I am running rxirc (very modified), on a IBM Maineframe
>and I would like to implement a /dcc function. Does anyone out there
>happen to know/have where maybe some specs are, or perhaps have some
>C code for /dcc sitting on their directory that they could mail me?
Well.. DCC is a ircII thing. There is no spec, the C-code is not too
good IMO. There are some other peole who has actualy done a DCC for
other clients.
The only thing DCC is good for is filetransfer. If you want to talk privately,
why not use talk(1) or the telephone.
For filetransfer there are a few of us who are working on alternative,
standalone programs. One for giving files (server) and one for fetching
files (client). At the present this is based on the FSP-suite of programs.
[FSP is a stateless UDP protocoll using 1K packets.]
But nothing is set yet. We may or may not go for this approach.
\Ruben.
--
Ove Ruben R Olsen a Gnarfer and VI user. EMAIL: ru...@uib.no.
Maintaining the EX/VI-archive and a couple of the Comp.Editors FAQs.
People that are ignorant tend to live a frustrated life, at least when
it comes to editing - But I do belive this is a general rule in life
Mark Evans
: The Beast upon your shoulder writes:
:
: >I am not on unix, I am running rxirc (very modified), on a IBM Maineframe
: >and I would like to implement a /dcc function. Does anyone out there
: >happen to know/have where maybe some specs are, or perhaps have some
: >C code for /dcc sitting on their directory that they could mail me?
:
: Well.. DCC is a ircII thing. There is no spec, the C-code is not too
: good IMO. There are some other peole who has actualy done a DCC for
: other clients.
Not too good is an understatement, one version I have seen crashed both clients
when using it between 2 on the same machine!!
It may work better in newer versions of ircII, but are you sure about
the other person running an up to date client
--
-------------------------------------------------------------------------
Mark Evans |eva...@uhura.aston.ac.uk
+(44) 21 429 9199 (Home) |eva...@cs.aston.ac.uk
+(44) 21 359 6531 x4039 (Office) |
Olaf Titz
> I am not on unix, I am running rxirc (very modified), on a IBM Maineframe
> and I would like to implement a /dcc function. Does anyone out there
> happen to know/have where maybe some specs are, or perhaps have some
As far as I know, the only 'specification' that exists for /dcc is the
actual implementation in ircII. Anyway, here is what I consider to be
the DCC 'protocol', as I read it out of the source for my own
implementation. (Which does work, if anyone doubts :-)
-------------------------------------------------------------------------------
Documentation of DCC CHAT and SEND protocol
by Olaf Titz (s_t...@ira.uka.de), 1993
DCC allows for direct connections between clients. Data sent over DCC
does not touch the server network. Only the request message initiating
a DCC connection gets sent via the servers. The request gets sent by
the client of the user who first issues the DCC command. When the
other part issues the accepting DCC command on a pending request, the
client does not send a message, but just opens the connection.
The client initiating a DCC connection opens a listening TCP socket
and sends a request message. The other part answers by connecting to
that socket. A connection is not closed explicitly; it can be
terminated at any time by either part by closing the socket. There is
no special provision for refusing a connection; this gets done by
simply not answering a request.
The request message is a CTCP privmsg is of the form:
DCC <type> <description> <ip-addr> <portnum>
(i.e. the command
PRIVMSG <target> :\001DCC <type> <description> <ip-addr> <portnum>\001
)
where
<target> is the target's nick
<type> is the type of the request: CHAT, TALK or SEND
<description> is a description, usually (chat) for CHAT,
and the filename for SEND
<ip-addr> is the requester's own IP address
<portnum> is the requestor socket port number
The fields are separated by spaces and must be all present.
ip-addr and portnum are given as unsigned 32-bit numbers in ASCII
format (i.e. IP address 0.1.2.3 is 66051)
The specific protocols are:
CHAT - consists of simply sending lines over the connection
TALK - is (as far as I know) an implementation of the Unix talk(1) protocol
GET is only used internally by the client to accept a SEND request. It
doesn't get sent as a request by itself, i.e. a file transfer has to
be requested by the sender.
SEND: The requester sends blocks of data over the connection. The
receiver repeatedly sends as acknowledge the number of bytes already
received, as 4-byte binary numbers with the top byte leading
(big-endian). The sender doesn't send the next block until all data
sent so far has been acknowledged. When the whole file is transmitted,
the sender closes the connection after waiting for the last ack. The
block size is not specified.
The files are transmitted without any data conversion (binary mode).
If text files are to be sent, the conversion can be implemented in
non-Unix clients so that files are sent over the network in Unix
format (i.e. LF as line separator, and the ISO Latin-1 charset is
used.) [This paragraph specified by me, sample implementation to be
found in ircle.]
Example: (A sends B a file of 10000 bytes. A has a send buffer of 8192
bytes, B has a receive of 4096 bytes, no network delays)
A B
CTCP message: DCC SEND file 6352617 9782 ->
connects to 6352617,port 9782
(All further conversation via the direct connection)
sends 8192 bytes ->
sends '4096'
sends '8192'
<-
sends 1808 bytes ->
sends '10000'
closes connection
-------------------------------------------------------------------------------
Olaf
--
| Olaf Titz - comp.sc.student | o | uk...@dkauni2.bitnet | old address |
| univ. of karlsruhe - germany | _>\ _ | s_t...@ira.uka.de | is still |
| +49-721-60439 | (_)<(_) | praetorius@irc | valid |
"My heart is human - my blood is boiling - my brain IBM" - Mr. Roboto
matthew green
>The only thing DCC is good for is filetransfer. If you want to talk privately,
>why not use talk(1) or the telephone.
When you message someone a lot on irc, and are also talking to a lot of
people on channel.. or even messaging a lot of people.. DCC CHAT is
very nice. Its fast, it isn't bothered by net splits.. it doesn't
(aside the initial request) use the irc net at all, so saving bandwidth
here.. Perhaps you need to try DCC CHAT some time.. I'd imagine
I talk as much in that as I do on channels...
phone..
Ove Ruben R Olsen
> Perhaps you need to try DCC CHAT some time.. I'd imagine
>I talk as much in that as I do on channels...
Then give me the spec so that I can implement it in my client >:)
\Ruben.
(Refuses do implement anything undocumented >:)
Troy Rollo
> Ove Ruben R Olsen (bu...@alf.uib.no) wrote:
> : Well.. DCC is a ircII thing. There is no spec, the C-code is not too
> : good IMO. There are some other peole who has actualy done a DCC for
> : other clients.
There *is* a specification, and it has been available on request since
about two months after it became popular. It has also been posted here,
and, if memory serves me correctly, to operlist.
As for the other, well, nobody asked you. Presumably you're talking about
lack of comments. The comments aren't there because to any competent
programmer it should be obvious.
> Not too good is an understatement, one version I have seen crashed both clients
> when using it between 2 on the same machine!!
There was a modified version of DCC that had the potential to do this,
so I refused to add it into the mainstream distribution. Other people
incorperated it into their own copies, and one popular set of patches
incorperated it, so as far as I am concerned, if it crashed a client
because of this, that's your own fault.
To my knowledge the original version of DCC never did this, and shouldn't
have had the potential to do this. If it did, and you didn't report it,
then that's your own stupid fault too. Coders cannot be expected to
fix bugs that haven't even been reported to them and don't occur on
any of the platforms they use.
In short, you are way, way out of line.
For the mindless whiners who go about blabbering to everybody that *snif*
they can't impliment DCC because no specification exists, here is the
specification, which has existed at least since:
6 -rwx------+ 1 troy 5122 Oct 24 1991 misc/dcc.doc
So there are obviously a few people around here who ought to get
their facts straight before mouthing off about a documented *and*
working protocol.
Incidentally, one of the biggest users of the DCC protocol since the
outset happens to be one of my least favourite people on the planet,
so you can be sure I would have heard *all* about it long ago if
there were genuine problems in the original protocol.
A description of the DCC protocol
=================================
By Troy Rollo (tr...@plod.cbme.unsw.oz.au)
(In response for requests for the protocol to be
documented).
The first comment I should make is that the DCC protocol
was never designed to be portable to clients other than IRCII.
As such I take no responsibility for it being difficult to
implement for other clients.
Why DCC?
========
DCC allows the user to overcome some limitations
of the IRC server network and to have the ultimate in secure
chat connections while still in an IRC oriented protocol.
DCC uses direct TCP connections between the clients
taking part to carry data. There is no flood control, so
packets can be sent at full speed, and there is no
dependance on server links (or load imposed on them). In
addition, since only the initial handshake for DCC conections
is passed through the IRC network, it is impossible for
Operators with cracked servers to spy on DCC messages.
How?
====
The initial socket for a DCC connection is created
by the side that initiates (Offers) the connection. This socket
should be a TCP socket bound to INADDR_ANY, listening for
connections.
The Initiating client, on creating the socket, should
send its details to the target client using the CTCP command
DCC. This command takes the form:
DCC type argument address port
type - The connection type
argument - The connectin type dependant argument
address - the host address of the initiator as an integer.
port - the port or the socket on which the initiator expects
to receive the connection.
The address and port should be sent as ascii representations of the
decimal integer formed by converting the values to host byte order
and treating them as an unsigned long and unsigned short respectively.
The following DCC connection types are known to IRCII:
Type Purpose Argument
CHAT To carry a secure conversation the string "chat"
SEND To send a file to the recipient the file name
In addition, the following are included in the IRCII DCC command,
although they do not transmit a DCC request via IRC:
TALK Establishes a TALK connection
Implementation
==============
The CHAT and SEND connection types should not be
accepted automatically as this would create the potential for
terrorism. Instead, they should notify the user that an
offer has been made, and allow the user to accept it.
The recipient should have the opportunity to rename
a file send with the DCC SEND command prior to retrieving
it.
The following are the steps which should occur in
the clients:
Initiator:
DCC command issued.
Create a socket, bind it to INADDR_ANY, port 0, and
make it passive (a listening socket).
Send the recipient a DCC request via CTCP supplying
the address and port of the socket. (This
is ideally taken from the address of the local
side of the socket which is connected to a
server. This is presumably the interface on
the host which is closest to the rest of
the net, and results in one less routing hop
in the case of gateway nodes).
Continue normally until a connection is received.
On a connection:
Accept the connection.
Close the original passive socket.
Conduct transaction on the new socket.
Acceptor:
CTCP DCC request received.
Record information on the DCC request and notify the user.
At this point, the USER should be able to abort (close) the
request, or accept it. The request should be accepted with
a command specifying the sender, type, and argument, or
a subset of these where no ambiguity exists.
If accepted, create a TCP socket.
Connect the new socket to the address and port supplied.
Conduct the transaction over the socket.
Type specific details.
======================
CHAT Data sent across a CHAT connection should be sent line-by-line
without any prefixes or commands. A CHAT connection ends when
one party issues the DCC CLOSE command to their clients, which
causes the socket to be closed and the information on the connection
to be discarded.
FILE Data is sent in packets, rather than dumped in a stream manner.
This allows the DCC SEND connection to survive where an FTP
connection might fail. The size of the packets is up to the
client, and may be set by the user. Smaller packets result
in a higher probability of survival over bad links.
The recipient should acknowledge each packet by transmitting
the total number of bytes received as an unsigned, 4 byte
integer in network byte order. The sender should not continue
to transmit until the recipient has acknowledged all data
already transmitted. Additionally, the sender should not
close the connection until the last byte has been
acknowledged by the recipient.
Note that it is not possible for the recipient to tell if the
entire file has been received - only the sender has that
information, although IRCII does not report it. Users generally
verify the transfer by checking file sizes.
Note also that no provision is made for text translation.
The block size used by IRCII is BIG_BUFFER_SIZE (1024).
This should probably be reviewed and reduced.
--
_______________________________________________________________________________
tr...@cbme.unsw.EDU.AU Overworked, overcommited and always multitasking.
Opinions expressed are not those of the CBME or UNSW, but are my opinions only.
You are free to adopt them. I suggest you adopt them. You will adopt them!
The Long Haired One
|> matthew green writes:
> Perhaps you need to try DCC CHAT some time.. I'd imagine
>I talk as much in that as I do on channels...
|> Then give me the spec so that I can implement it in my client >:)
|> \Ruben.
|> (Refuses do implement anything undocumented >:)
About a year ago or whenever it came out, I remember someone having an
official document on how DCC worked. Probably the person who introduced it.
Unfortunately, I don't have a copy of it, but its out there somewhere.
its like CTCP, there is full documentation out there for it, just gotta
know where to find, and pray people know how to read it and implement it
properly :)
By the way things are going, if someone has the official docs, they should
probably post it again :)
-Rocker
An emacs client coder
Mark Evans
:
: Initiator:
: DCC command issued.
: Create a socket, bind it to INADDR_ANY, port 0, and
: make it passive (a listening socket).
: Send the recipient a DCC request via CTCP supplying
: the address and port of the socket. (This
: is ideally taken from the address of the local
: side of the socket which is connected to a
: server. This is presumably the interface on
: the host which is closest to the rest of
: the net, and results in one less routing hop
: in the case of gateway nodes).
: Continue normally until a connection is received.
How about having the recipient also be able to send a REFUSE CTCP back
which will cause the socket the requester is holding to be closed.
(possibly also a timeout on DCC requests)
(avoids hogging resorces)
:
: On a connection:
: Accept the connection.
could also put in a check that the host connecting to you is what you
expect it to be
: Close the original passive socket.
(while this is open anyone who knows it's port number can connect to it,
should be just the client you are trying to contact. Anyone who can run
a program such as netstat on your machine can find this out)
: Conduct transaction on the new socket.
:
: Acceptor:
: CTCP DCC request received.
: Record information on the DCC request and notify the user.
:
: At this point, the USER should be able to abort (close) the
(aborting by sending a message back to the user which will notify them
and clean up things at their end)
: request, or accept it. The request should be accepted with
: a command specifying the sender, type, and argument, or
: a subset of these where no ambiguity exists.
:
: If accepted, create a TCP socket.
: Connect the new socket to the address and port supplied.
: Conduct the transaction over the socket.
Is a DCC REFUSE command currently included?
:
Olaf Titz
> How about having the recipient also be able to send a REFUSE CTCP back
> which will cause the socket the requester is holding to be closed.
Could be an idea, needs only to be implemented.
> : Accept the connection.
> could also put in a check that the host connecting to you is what you
> expect it to be
But how do you verify, no, how do you *know* what you expect it to be?
> (while this is open anyone who knows it's port number can connect to it,
> should be just the client you are trying to contact. Anyone who can run
> a program such as netstat on your machine can find this out)
Surely, there is a security hole. But I see no provision for fixing it
while remaining compatible to the now existing thing.
You could perhaps issue a WHOIS to find out the *host* of the other
part, but not more. (Requesting the username too via an authentication
server would throw out too many users, I suspect, and decreasing the
chance that this protocol will be implemented in more client versions.)
> Is a DCC REFUSE command currently included?
You can DCC CLOSE the request, which will clean things up at your
side, but not signal back to the requestor.
Troy Rollo
> How about having the recipient also be able to send a REFUSE CTCP back
> which will cause the socket the requester is holding to be closed.
Generally if somebody doesn't want a file, it's unlikely to be offered to them.
If the user wants to cancel the offer, they can at any time.
> (possibly also a timeout on DCC requests)
That's not a protocol issue.
> (avoids hogging resorces)
An idle socket doesn't cost much in resources because no mbufs are allocated
to it yet.
> (while this is open anyone who knows it's port number can connect to it,
> should be just the client you are trying to contact. Anyone who can run
> a program such as netstat on your machine can find this out)
Anyone can do this with talk and ftp too. Of course, they have to figure
out which of usually several open connections they are aiming to get at.
This is also a client private consideration, not a protocol consideration.
> : At this point, the USER should be able to abort (close) the
>
> (aborting by sending a message back to the user which will notify them
> and clean up things at their end)
In practice, about the only time this feature will be used is when somebody
sends a DCC request maliciously (somebody you wouldn't want to talk to
or somebody trying to send a file to replace one in your home directory).
> Is a DCC REFUSE command currently included?
No, but it would be simple to alias it.
ALIAS REFUSE
{
CTCP $1 REFUSE $0 $2
DCC CLOSE $0 $1 $2
}
ON ^CTCP "% % REFUSE % %"
{
if ( [$1] == N )
{
^DCC CLOSE $3 $0 $4
if ([$4])
{
echo *** DCC $3 \($4\) to $0 refused
}
{
echo *** DCC $3 (any) to $0 refused