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., 51 Franklin St., 22 Fifth Floor, Boston, MA 02110-1301 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 /* 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 52 53 typedef struct dcc_file_transfer { 54 55 struct im_connection *ic; 56 57 /* 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. 61 */ 62 int fd; 63 64 /* 65 * IDs returned by b_input_add for watch_ing over the above socket. 66 */ 67 gint watch_in; /* readable */ 68 gint watch_out; /* writable */ 69 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; 73 74 /* 75 * The total amount of bytes that have been sent to the irc client. 76 */ 77 size_t bytes_sent; 78 79 /* 80 * Handle the wonderful sadly-not-deprecated ACKs. 81 */ 82 guint32 acked; 83 int acked_len; 84 85 /* imc's handle */ 86 file_transfer_t *ft; 87 88 /* if we're receiving, this is the sender's socket address */ 89 struct sockaddr_storage saddr; 90 91 /* set to true if the protocol has finished 92 * (i.e. called imcb_file_finished) 93 */ 94 int proto_finished; 95 } dcc_file_transfer_t; 96 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); 104 105 #endif 106