From 985d66d3f99046583175fe44e125e54b666f3c51 Mon Sep 17 00:00:00 2001 From: dequis Date: Sat, 24 Sep 2016 23:21:59 -0300 Subject: twitter: don't count filter stream reply as valid pongs Twitter streams send newlines to indicate that they are alive. The twitter_http_stream() function processes those and sets the ponged flag so that the whole connection doesn't timeout. That function is used to handle both user stream and filter stream. If the user stream is dead (not sending whitespace) but the filter stream isn't, the latter keeps the connection alive while the main twitter channel is completely dead. This commit only sets the ponged flag for the user stream. This has the side effect of not detecting if the filter stream dies - but that didn't work before, anyway. In the future the whole stream connection management should be revamped - for example stream disconnections shouldn't take the whole account down, especially not filter streams. --- protocols/twitter/twitter_lib.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'protocols') diff --git a/protocols/twitter/twitter_lib.c b/protocols/twitter/twitter_lib.c index f1274952..ad019e1d 100644 --- a/protocols/twitter/twitter_lib.c +++ b/protocols/twitter/twitter_lib.c @@ -1018,7 +1018,6 @@ static void twitter_http_stream(struct http_request *req) return; } - ic->flags |= OPT_PONGED; td = ic->proto_data; if ((req->flags & HTTPC_EOF) || !req->reply_body) { @@ -1036,6 +1035,10 @@ static void twitter_http_stream(struct http_request *req) return; } + if (req == td->stream) { + ic->flags |= OPT_PONGED; + } + /* MUST search for CRLF, not just LF: https://dev.twitter.com/docs/streaming-apis/processing#Parsing_responses */ if (!(nl = strstr(req->reply_body, "\r\n"))) { -- cgit v1.2.3 From 1a8875ffaae873853fd8537cdce43e35e9889266 Mon Sep 17 00:00:00 2001 From: dequis Date: Sun, 25 Sep 2016 00:07:25 -0300 Subject: purple: Fix another issue where /join results in two channels Follow up to a3019499665384a3dcbbc11016d256e6d4dcd26c (which actually made things worse than before for this particular case - found it by bisecting) This affected skypeweb and hangouts, maybe others. Sometimes serv_join_chat() results in a call chain like this (outermost frame first) 1. purple_chat_join 2. serv_join_chat 3. (the join_chat function of the prpl) 4. serv_got_joined_chat 5. purple_conversation_new 6. prplcb_conv_new The last one tries to find a struct groupchat by name (that's the code from the referenced commit). If it doesn't exist, it creates a new one. This usually isn't an issue because the 4th step is done asynchronously, and a groupchat is created at the end of purple_chat_join. If it's not, you end up with two groupchats, which can lead to other nasty issues. This moves the creation of the groupchat right before serv_join_chat(). That way, it always exists even if the conversation is created immediately. --- protocols/purple/purple.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'protocols') diff --git a/protocols/purple/purple.c b/protocols/purple/purple.c index 6c8ddf0d..374b826b 100644 --- a/protocols/purple/purple.c +++ b/protocols/purple/purple.c @@ -722,6 +722,7 @@ struct groupchat *purple_chat_join(struct im_connection *ic, const char *room, c PurplePluginProtocolInfo *pi = prpl->info->extra_info; GHashTable *chat_hash; PurpleConversation *conv; + struct groupchat *gc; GList *info, *l; if (!pi->chat_info || !pi->chat_info_defaults || @@ -755,11 +756,14 @@ struct groupchat *purple_chat_join(struct im_connection *ic, const char *room, c g_list_free(info); + /* do this before serv_join_chat to handle cases where prplcb_conv_new is called immediately (not async) */ + gc = imcb_chat_new(ic, room); + serv_join_chat(purple_account_get_connection(pd->account), chat_hash); g_hash_table_destroy(chat_hash); - return imcb_chat_new(ic, room); + return gc; } void purple_chat_list(struct im_connection *ic, const char *server) -- cgit v1.2.3