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 | /* Send an ACK after receiving this amount of data */ |
---|
47 | #define DCC_PACKET_SIZE 1024 |
---|
48 | |
---|
49 | typedef struct dcc_file_transfer { |
---|
50 | |
---|
51 | struct im_connection *ic; |
---|
52 | |
---|
53 | /* |
---|
54 | * Depending in the status of the file transfer, this is either the socket that is |
---|
55 | * being listened on for connections, or the socket over which the file transfer is |
---|
56 | * taking place. |
---|
57 | */ |
---|
58 | int fd; |
---|
59 | |
---|
60 | /* |
---|
61 | * IDs returned by b_input_add for watch_ing over the above socket. |
---|
62 | */ |
---|
63 | gint watch_in; /* readable */ |
---|
64 | gint watch_out; /* writable */ |
---|
65 | |
---|
66 | /* |
---|
67 | * The total amount of bytes that have been sent to the irc client. |
---|
68 | */ |
---|
69 | size_t bytes_sent; |
---|
70 | |
---|
71 | /* imc's handle */ |
---|
72 | file_transfer_t *ft; |
---|
73 | |
---|
74 | /* if we're receiving, this is the sender's socket address */ |
---|
75 | struct sockaddr_storage saddr; |
---|
76 | |
---|
77 | } dcc_file_transfer_t; |
---|
78 | |
---|
79 | file_transfer_t *dccs_send_start( struct im_connection *ic, char *user_nick, char *file_name, size_t file_size ); |
---|
80 | |
---|
81 | void dcc_canceled( file_transfer_t *file, char *reason ); |
---|
82 | |
---|
83 | gboolean dccs_send_write( file_transfer_t *file, char *data, unsigned int data_size ); |
---|
84 | |
---|
85 | file_transfer_t *dcc_request( struct im_connection *ic, char *line ); |
---|
86 | #endif |
---|