aboutsummaryrefslogtreecommitdiffstats
path: root/protocols/ft.h
blob: 65877c7df92dc86e76581e27fc78e11a03914290 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
/********************************************************************\
* BitlBee -- An IRC to other IM-networks gateway                     *
*                                                                    *
* Copyright 2006 Marijn Kruisselbrink and others                     *
\********************************************************************/

/* Generic file transfer header                                     */

/*
  This program is free software; you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
  the Free Software Foundation; either version 2 of the License, or
  (at your option) any later version.

  This program is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  GNU General Public License for more details.

  You should have received a copy of the GNU General Public License with
  the Debian GNU/Linux distribution in /usr/share/common-licenses/GPL;
  if not, write to the Free Software Foundation, Inc., 51 Franklin St.,
  Fifth Floor, Boston, MA  02110-1301  USA
*/

#ifndef _FT_H
#define _FT_H

/*
 * One buffer is needed for each transfer. The receiver stores a message
 * in it and gives it to the sender. The sender will stall the receiver
 * till the buffer has been sent out.
 */
#define FT_BUFFER_SIZE 2048

typedef enum {
	FT_STATUS_LISTENING	= 1,
	FT_STATUS_TRANSFERRING	= 2,
	FT_STATUS_FINISHED	= 4,
	FT_STATUS_CANCELED	= 8,
	FT_STATUS_CONNECTING	= 16
} file_status_t;

/*
 * This structure holds all irc specific information regarding an incoming (from the point of view of
 * the irc client) file transfer. New instances of this struct should only be created by calling the
 * imcb_file_send_start() method, which will initialize most of the fields. The data field and the various
 * methods are zero-initialized. Instances will automatically be deleted once the transfer is completed,
 * canceled, or the connection to the irc client has been lost (note that also if only the irc connection
 * and not the file transfer connection is lost, the file transfer will still be canceled and freed).
 *
 * The following (poor ascii-art) diagram illustrates what methods are called for which status-changes:
 *
 *	                        /-----------\                    /----------\
 *	               -------> | LISTENING | -----------------> | CANCELED |
 *	                        \-----------/  [canceled,]free   \----------/
 *	                              |
 *	                              | accept
 *	                              V
 *	               /------ /-------------\                    /------------------------\
 *	   out_of_data |       | TRANSFERING | -----------------> | TRANSFERING | CANCELED |
 *	               \-----> \-------------/  [canceled,]free   \------------------------/
 *	                              |
 *	                              | finished,free
 *	                              V
 *	                 /------------------------\
 *	                 | TRANSFERING | FINISHED |
 *	                 \------------------------/
 */
typedef struct file_transfer {

	/* Are we sending something? */
	int sending;

	/*
	 * The current status of this file transfer.
	 */ 
	file_status_t status;
	
	/*
	 * file size
	 */
	size_t file_size;
	
	/*
	 * Number of bytes that have been successfully transferred.
	 */
	size_t bytes_transferred;

	/*
	 * Time started. Used to calculate kb/s.
	 */
	time_t started;

	/*
	 * file name
	 */
	char *file_name;

	/*
	 * A unique local ID for this file transfer.
	 */
	unsigned int local_id;

	/*
	 * IM-protocol specific data associated with this file transfer.
	 */
	gpointer data;
	struct im_connection *ic;
	
	/*
	 * Private data.
	 */
	gpointer priv;
	
	/*
	 * If set, called after succesful connection setup.
	 */
	void (*accept) ( struct file_transfer *file );
	
	/*
	 * If set, called when the transfer is canceled or finished.
	 * Subsequently, this structure will be freed.
	 *
	 */
	void (*free) ( struct file_transfer *file );
	
	/*
	 * If set, called when the transfer is finished and successful.
	 */
	void (*finished) ( struct file_transfer *file );
	
	/*
	 * If set, called when the transfer is canceled.
	 * ( canceled either by the transfer implementation or by
	 *  a call to imcb_file_canceled )
	 */
	void (*canceled) ( struct file_transfer *file, char *reason );
	
	/*
	 * called by the sending side to indicate that it is writable.
	 * The callee should check if data is available and call the 
	 * function(as seen below) if that is the case.
	 */
	gboolean (*write_request) ( struct file_transfer *file );

	/*
	 * When sending files, protocols register this function to receive data.
	 * This should only be called once after write_request is called. The caller
	 * should not read more data until write_request is called again. This technique
	 * avoids buffering.
	 */
	gboolean (*write) (struct file_transfer *file, char *buffer, unsigned int len );

	/* The send buffer associated with this transfer.
	 * Since receivers always wait for a write_request call one is enough.
	 */
	char buffer[FT_BUFFER_SIZE];

} file_transfer_t;

/*
 * This starts a file transfer from bitlbee to the user.
 */
file_transfer_t *imcb_file_send_start( struct im_connection *ic, char *user_nick, char *file_name, size_t file_size );

/*
 * This should be called by a protocol when the transfer is canceled. Note that
 * the canceled() and free() callbacks given in file will be called by this function.
 */
void imcb_file_canceled( struct im_connection *ic, file_transfer_t *file, char *reason );

gboolean imcb_file_recv_start( struct im_connection *ic, file_transfer_t *ft );

void imcb_file_finished( struct im_connection *ic, file_transfer_t *file );
#endif
an class="w"> if( bud && ( cap = xt_find_node( node->children, "c" ) ) && ( s = xt_find_attr( cap, "xmlns" ) ) && strcmp( s, XMLNS_CAPS ) == 0 ) { /* This <presence> stanza includes an XEP-0115 capabilities part. Not too interesting, but we can see if it has an ext= attribute. */ s = xt_find_attr( cap, "ext" ); if( s && ( strstr( s, "cstates" ) || strstr( s, "chatstate" ) ) ) bud->flags |= JBFLAG_DOES_XEP85; /* This field can contain more information like xhtml support, but we don't support that ourselves. Officially the ext= tag was deprecated, but enough clients do send it. (I'm aware that this is not the right way to use this field.) See for an explanation of ext=: http://www.xmpp.org/extensions/attic/xep-0115-1.3.html*/ } if( is_chat ) jabber_chat_pkt_presence( ic, bud, node ); else send_presence = jabber_buddy_by_jid( ic, bud->bare_jid, 0 ); } else if( strcmp( type, "unavailable" ) == 0 ) { if( ( bud = jabber_buddy_by_jid( ic, from, 0 ) ) == NULL ) { /* imcb_log( ic, "Warning: Received presence information from unknown JID: %s", from ); */ return XT_HANDLED; } /* Handle this before we delete the JID. */ if( is_chat ) { jabber_chat_pkt_presence( ic, bud, node ); } if( strchr( from, '/' ) == NULL ) /* Sometimes servers send a type="unavailable" from a bare JID, which should mean that suddenly all resources for this JID disappeared. */ jabber_buddy_remove_bare( ic, from ); else jabber_buddy_remove( ic, from ); if( is_chat ) { /* Nothing else to do for now? */ } else if( ( s = strchr( from, '/' ) ) ) { *s = 0; /* If another resource is still available, send its presence information. */ if( ( send_presence = jabber_buddy_by_jid( ic, from, 0 ) ) == NULL ) { /* Otherwise, count him/her as offline now. */ imcb_buddy_status( ic, from, 0, NULL, NULL ); } *s = '/'; } else { imcb_buddy_status( ic, from, 0, NULL, NULL ); } } else if( strcmp( type, "subscribe" ) == 0 ) { jabber_buddy_ask( ic, from ); } else if( strcmp( type, "subscribed" ) == 0 ) { /* Not sure about this one, actually... */ imcb_log( ic, "%s just accepted your authorization request", from ); } else if( strcmp( type, "unsubscribe" ) == 0 || strcmp( type, "unsubscribed" ) == 0 ) { /* Do nothing here. Plenty of control freaks or over-curious souls get excited when they can see who still has them in their buddy list and who finally removed them. Somehow I got the impression that those are the people who get removed from many buddy lists for "some" reason... If you're one of those people, this is your chance to write your first line of code in C... */ } else if( strcmp( type, "error" ) == 0 ) { return jabber_cache_handle_packet( ic, node ); /* struct jabber_error *err; if( ( c = xt_find_node( node->children, "error" ) ) ) { err = jabber_error_parse( c, XMLNS_STANZA_ERROR ); imcb_error( ic, "Stanza (%s) error: %s%s%s", node->name, err->code, err->text ? ": " : "", err->text ? err->text : "" ); jabber_error_free( err ); } */ } if( send_presence ) { int is_away = 0; if( send_presence->away_state && strcmp( send_presence->away_state->code, "chat" ) != 0 ) is_away = OPT_AWAY; imcb_buddy_status( ic, send_presence->bare_jid, OPT_LOGGED_IN | is_away, is_away ? send_presence->away_state->full_name : NULL, send_presence->away_message ); } return XT_HANDLED; } /* Whenever presence information is updated, call this function to inform the server. */ int presence_send_update( struct im_connection *ic ) { struct jabber_data *jd = ic->proto_data; struct xt_node *node, *cap; GSList *l; int st; node = jabber_make_packet( "presence", NULL, NULL, NULL ); xt_add_child( node, xt_new_node( "priority", set_getstr( &ic->acc->set, "priority" ), NULL ) ); if( jd->away_state ) xt_add_child( node, xt_new_node( "show", jd->away_state->code, NULL ) ); if( jd->away_message ) xt_add_child( node, xt_new_node( "status", jd->away_message, NULL ) ); /* This makes the packet slightly bigger, but clients interested in capabilities can now cache the discovery info. This reduces the usual post-login iq-flood. See XEP-0115. At least libpurple and Trillian seem to do this right. */ cap = xt_new_node( "c", NULL, NULL ); xt_add_attr( cap, "xmlns", XMLNS_CAPS ); xt_add_attr( cap, "node", "http://bitlbee.org/xmpp/caps" ); xt_add_attr( cap, "ver", BITLBEE_VERSION ); /* The XEP wants this hashed, but nobody's doing that. */ xt_add_child( node, cap ); st = jabber_write_packet( ic, node ); /* Have to send this update to all groupchats too, the server won't do this automatically. */ for( l = ic->groupchats; l && st; l = l->next ) { struct groupchat *c = l->data; struct jabber_chat *jc = c->data; xt_add_attr( node, "to", jc->my_full_jid ); st = jabber_write_packet( ic, node ); } xt_free_node( node ); return st; } /* Send a subscribe/unsubscribe request to a buddy. */ int presence_send_request( struct im_connection *ic, char *handle, char *request ) { struct xt_node *node; int st; node = jabber_make_packet( "presence", NULL, NULL, NULL ); xt_add_attr( node, "to", handle ); xt_add_attr( node, "type", request ); st = jabber_write_packet( ic, node ); xt_free_node( node ); return st; }