source: dcc.h @ 2c2df7d

Last change on this file since 2c2df7d was 2c2df7d, checked in by ulim <a.sporto+bee@…>, at 2007-11-28T21:07:30Z

Initial import of jabber file receive and DCC send support. This introduces
only a few changes to bitlbees code, mainly the addition of the "transfers"
command.

This is known to work with Kopete, Psi, and Pidgin (formerly known as gaim).
At least with Pidgin also over a proxy. DCC has only been tested with irssi.
IPV6 is untested but should work.

Currently, only receiving via SOCKS5BYTESREAMS is implemented. I'm not sure if
the alternative(in-band bytestreams IBB) is worth implementing since I didn't
see a client yet that can do it. Additionally, it is probably very slow and
needs support by the server as well.

  • Property mode set to 100644
File size: 4.1 KB
RevLine 
[2c2df7d]1/********************************************************************\
2* BitlBee -- An IRC to other IM-networks gateway                     *
3*                                                                    *
4* Copyright 2006 Marijn Kruisselbrink and others                     *
5* Copyright 2007 Uli Meis <a.sporto+bee@gmail.com>                   *
6\********************************************************************/
7
8/*
9  This program is free software; you can redistribute it and/or modify
10  it under the terms of the GNU General Public License as published by
11  the Free Software Foundation; either version 2 of the License, or
12  (at your option) any later version.
13
14  This program is distributed in the hope that it will be useful,
15  but WITHOUT ANY WARRANTY; without even the implied warranty of
16  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
17  GNU General Public License for more details.
18
19  You should have received a copy of the GNU General Public License with
20  the Debian GNU/Linux distribution in /usr/share/common-licenses/GPL;
21  if not, write to the Free Software Foundation, Inc., 59 Temple Place,
22  Suite 330, Boston, MA  02111-1307  USA
23*/
24
25/*
26 * DCC SEND
27 *
28 * Historically, DCC means send 1024 Bytes and wait for a 4 byte reply
29 * acknowledging all transferred data. This is ridiculous for two reasons.  The
30 * first being that TCP is a stream oriented protocol that doesn't care much
31 * about your idea of a packet. The second reason being that TCP is a reliable
32 * transfer protocol with its own sophisticated ACK mechanism, making DCCs ACK
33 * mechanism look like a joke. For these reasons, DCCs requirements have
34 * (hopefully) been relaxed in most implementations and this implementation
35 * depends upon at least the following: The 1024 bytes need not be transferred
36 * at once, i.e. packets can be smaller. A second relaxation has apparently
37 * gotten the name "DCC SEND ahead" which basically means to not give a damn
38 * about those DCC ACKs and just send data as you please. This behaviour is
39 * enabled by default. Note that this also means that packets may be as large
40 * as the maximum segment size.
41 */ 
42
43#ifndef _DCC_H
44#define _DCC_H
45
46/* don't wait for acknowledgments */
47#define DCC_SEND_AHEAD
48
49/* This multiplier specifies how many bytes we
50 * can go ahead within one event loop cycle. Notice that all in all,
51 * we can easily be more ahead if the event loop shoots often enough.
52 * (or the receiver processes slow enough)
53 *
54 * Setting this value too high will cause send buffer overflows.
55 */
56#define DCC_SEND_AHEAD_MUL 10
57
58/*
59 * queue thresholds for the out of data and overflow conditions
60 */
61#define DCC_QUEUE_THRESHOLD_LOW 2048
62#define DCC_QUEUE_THRESHOLD_HIGH 65536
63
64/* only used in non-ahead mode */
65#define DCC_PACKET_SIZE 1024
66
67/* stores buffers handed over by IM protocols */
68struct dcc_buffer {
69        char *b;
70        int len;
71};
72
73typedef struct dcc_file_transfer {
74
75        struct im_connection *ic;
76
77        /*
78         * Depending in the status of the file transfer, this is either the socket that is
79         * being listened on for connections, or the socket over which the file transfer is
80         * taking place.
81         */
82        int fd;
83       
84        /*
85         * IDs returned by b_input_add for watch_ing over the above socket.
86         */
87        gint watch_in;   /* readable */
88        gint watch_out;  /* writable */
89       
90        /*
91         * The total number of queued bytes. The following equality should always hold:
92         *
93         *      queued_bytes = sum(queued_buffers.len) - buffer_pos
94         */
95        unsigned int queued_bytes;
96
97        /*
98         * A list of dcc_buffer structures.
99         * These are provided by the protocols directly so that no copying is neccessary.
100         */
101        GSList *queued_buffers;
102       
103        /*
104         * current position within the first buffer.
105         * Is non-null if the whole buffer couldn't be sent at once.
106         */
107        int buffer_pos;
108
109        /*
110         * The total amount of bytes that have been sent to the irc client.
111         */
112        size_t bytes_sent;
113       
114        /* imcb's handle */
115        file_transfer_t *ft;
116
117} dcc_file_transfer_t;
118
119file_transfer_t *dccs_send_start( struct im_connection *ic, char *user_nick, char *file_name, size_t file_size );
120
121void dcc_canceled( file_transfer_t *file, char *reason );
122
123gboolean dccs_send_write( file_transfer_t *file, gpointer data, unsigned int data_size );
124
125#endif
Note: See TracBrowser for help on using the repository browser.