Scan media entities as well, not just url entities. This should expand more
[bitlbee.git] / dcc.h
blobf3e7aa98a8824f5e7ff1b0b90881bc9fc75437c2
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 \********************************************************************/
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.
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.
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
25 /*
26 * DCC SEND
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 */
43 #ifndef _DCC_H
44 #define _DCC_H
46 /* Send an ACK after receiving this amount of data */
47 #define DCC_PACKET_SIZE 1024
49 /* Time in seconds that a DCC transfer can be stalled before being aborted.
50 * By handling this here individual protocols don't have to think about this. */
51 #define DCC_MAX_STALL 120
53 typedef struct dcc_file_transfer {
55 struct im_connection *ic;
58 * Depending in the status of the file transfer, this is either the socket that is
59 * being listened on for connections, or the socket over which the file transfer is
60 * taking place.
62 int fd;
65 * IDs returned by b_input_add for watch_ing over the above socket.
67 gint watch_in; /* readable */
68 gint watch_out; /* writable */
70 /* the progress watcher cancels any file transfer if nothing happens within DCC_MAX_STALL */
71 gint progress_timeout;
72 size_t progress_bytes_last;
75 * The total amount of bytes that have been sent to the irc client.
77 size_t bytes_sent;
80 * Handle the wonderful sadly-not-deprecated ACKs.
82 guint32 acked;
83 int acked_len;
85 /* imc's handle */
86 file_transfer_t *ft;
88 /* if we're receiving, this is the sender's socket address */
89 struct sockaddr_storage saddr;
91 /* set to true if the protocol has finished
92 * (i.e. called imcb_file_finished)
94 int proto_finished;
95 } dcc_file_transfer_t;
97 file_transfer_t *dccs_send_start( struct im_connection *ic, irc_user_t *iu, const char *file_name, size_t file_size );
98 void dcc_canceled( file_transfer_t *file, char *reason );
99 gboolean dccs_send_write( file_transfer_t *file, char *data, unsigned int data_size );
100 file_transfer_t *dcc_request( struct im_connection *ic, char* const* ctcp );
101 void dcc_finish( file_transfer_t *file );
102 void dcc_close( file_transfer_t *file );
103 gboolean dccs_recv_start( file_transfer_t *ft );
105 #endif