Bug 71195 - Sending long messages on AIM protocol disconnects account
Summary: Sending long messages on AIM protocol disconnects account
Status: RESOLVED FIXED
Alias: None
Product: kopete
Classification: Applications
Component: ICQ and AIM Plugins (show other bugs)
Version: 0.8.0
Platform: Compiled Sources Linux
: NOR major
Target Milestone: ---
Assignee: Kopete Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-12-25 00:42 UTC by Casey Allen Shobe
Modified: 2006-01-15 01:39 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Casey Allen Shobe 2003-12-25 00:42:52 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources
OS:          Linux

Tried to send a 966-character message to a contact, 30 seconds later (after several more messages reported normally sent without error (though the remote party never got them), AIM switched to offline.  Repeated, same result.

Message from mETz (mETz) 18:13:43
 so it might be too long
Message from mETz (mETz) 18:14:10
 the problem with splitting it up into several messages is getting the counting right
Message from mETz (mETz) 18:14:24
 you have to subtract the whole mess around the message itself
Message from mETz (mETz) 18:14:32
 and you have to take utf and stuff into account too
Message from mETz (mETz) 18:14:44
 that's why I never tried it, high risk of not doing it right

(oscar): [void OscarSocket::sendIM(const QString&, OscarContact*, bool)] SEND (CLI_SENDMSG), msg='<HTML><BODY BGCOLOR="#ffffff"><FONT COLOR="#000000"><FONT FACE="Anonymous">esuna=# \d+ pglogd.log_entries<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Table "pglogd.log_entries"<br>&nbsp; &nbsp; &nbsp; Column&nbsp; &nbsp; &nbsp; |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Type&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | Modifiers | Description<br>------------------+--------------------------+-----------+-------------<br> request_time&nbsp; &nbsp; | timestamp with time zone |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br> seconds_to_serve | integer&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br> response_code&nbsp; &nbsp; | integer&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br> bytes_sent&nbsp; &nbsp; &nbsp; | integer&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br> request_type&nbsp; &nbsp; | character varying(10)&nbsp; &nbsp; |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br> virtual_domain&nbsp; | character varying(80)&nbsp; &nbsp; |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br> remote_host&nbsp; &nbsp; &nbsp; | character varying(80)&nbsp; &nbsp; |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br> request_url_path | character varying(80)&nbsp; &nbsp; |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br> referer&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | text&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br> user_agent&nbsp; &nbsp; &nbsp; | text&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br> request&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | text&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br> logname&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | character varying(30)&nbsp; &nbsp; |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br> username&nbsp; &nbsp; &nbsp; &nbsp; | character varying(30)&nbsp; &nbsp; |&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |<br></FONT></FONT></BODY></HTML>' to 'shobe1knobe'
kopete (oscar): [void OscarSocket::sendIM(const QString&, OscarContact*, bool)] Outgoing message encoded as 'ISO 8859-1'
kopete (oscar): [void OscarSocket::sendBuf(Buffer&, unsigned char)] writeBlock() call failed!
kopete (oscar): [void OscarSocket::sendBuf(Buffer&, unsigned char)] Resource temporarily unavailable
Comment 1 Casey Allen Shobe 2003-12-25 00:44:08 UTC
And after 30 seconds or so...the account disconnects:

kopete (oscar): [void OscarSocket::slotConnectionClosed()] Connection for account 'SomeLinuxGuy' closed.
kopete (oscar): [void OscarSocket::slotConnectionClosed()] Socket Status: Connection reset by peer
kopete (oscar): [void OscarSocket::slotConnectionClosed()] emitting statusChanged(OSCAR_OFFLINE)
kopete (oscar): [void OscarAccount::slotOurStatusChanged(unsigned int)] Called; newStatus=0
kopete: [void KopeteContactListView::slotSort()]

Shouldn't it ought disconnect immediately if it cannot recover?
Comment 2 Thiago Macieira 2003-12-25 05:56:10 UTC
Interesting, KExtendedSocket::writeBlock is returning -1 in a buffered socket. That shouldn't happen.
Comment 3 Matt Rogers 2003-12-30 07:00:41 UTC
not a showstopper
Comment 4 Martijn Klingens 2003-12-30 12:10:11 UTC
Subject: Re: [Kopete-devel]  Sending long messages on AIM protocol disconnects account

On Tuesday 30 December 2003 07:00, Matt Rogers wrote:
> not a showstopper

No, but definitely a very severe bug. We *can* ship Kopete with the bug open, 
but it's the first one on the list to fix once the real showstoppers are 
gone.

Comment 5 Marcelo Penna Guerra 2003-12-30 20:33:09 UTC
Well, I have a patch to split messages in blocks no longer than the AIM size limit (according to AIM official windows client, 1024 chars), but it's sending the messages too fast. If anyone know how do I put a small interval between them, the bug will probably be fixed.
Comment 6 Matt Rogers 2003-12-30 22:20:18 UTC
Subject: Re:  Sending long messages on AIM protocol disconnects account

On Tuesday 30 December 2003 01:33 pm, Marcelo Penna Guerra wrote:
> Well, I have a patch to split messages in blocks no longer than the
> AIM size limit (according to AIM official windows client, 1024 chars), but
> it's sending the messages too fast. If anyone know how do I put a small
> interval between them, the bug will probably be fixed.

I have an idea for this as well, but it will take some thinking on how to make 
it work correctly and not be a complete hack.

Comment 7 Martijn Klingens 2003-12-31 01:45:13 UTC
Subject: Re: [Kopete-devel]  Sending long messages on AIM protocol disconnects account

On Tuesday 30 December 2003 22:20, Matt Rogers wrote:
> I have an idea for this as well, but it will take some thinking on how to
> make it work correctly and not be a complete hack.

Use a QValueList (or whatever else data structure that allows adding entries 
in a fixed order) and append what needs to be sent to the end. At the same 
time set a singleShot timer and when it fires pop the first entry from the 
front. When the queue isn't empty just reschedule the timer.

MSN does the same with a 0-second timer in msnsocket.cpp to avoid blocking the 
GUI, but if you change the timings you can basically borrow the algorithm.

I also seem to remember I mailed some thoughts on decent rate limiting to Matt 
in private mail. Do you still have them?

Comment 8 Matt Rogers 2003-12-31 02:14:35 UTC
Subject: Re:  Sending long messages on AIM protocol disconnects account

> On Tuesday 30 December 2003 22:20, Matt Rogers wrote:
> > I have an idea for this as well, but it will take some thinking on how to
> > make it work correctly and not be a complete hack.
>
> Use a QValueList (or whatever else data structure that allows adding
> entries in a fixed order) and append what needs to be sent to the end. At
> the same time set a singleShot timer and when it fires pop the first entry
> from the front. When the queue isn't empty just reschedule the timer.
>

/me looks at the code he wrote. We're using a QValueList now for the packet 
queues, but the queue's only used for rate limiting purposes, and other than 
that one bug that pointed out an error in the logic that I was using, it 
would seem to work fine (and we haven't gotten any other bug reports about 
it, so I have to assume that it does work). So, basically, the queueing of 
packets used for rate limiting would have to be generalized to handle some of 
the other ways we might want to rate limit packets as well.

> MSN does the same with a 0-second timer in msnsocket.cpp to avoid blocking
> the GUI, but if you change the timings you can basically borrow the
> algorithm.
>
> I also seem to remember I mailed some thoughts on decent rate limiting to
> Matt in private mail. Do you still have them?

Yes, I still have them. :)

Comment 9 Matt Rogers 2003-12-31 05:10:08 UTC
Re #1: No, because the servers are the ones that disconnect us. The server doesn't send back an error, just disconnects us. see below for an explaination.

Re #2: with an EAGAIN error code, at least from what I can tell by looking at the man pages. the man page for write suggests that the error message comes from the fact that the socket would block if the write was to actually occur.

Re #5: I'm testing the patch right now and it seems to work correctly. I have the limit set really low though, I'l try bumping it and seeing what happens. I imagine we'll need to make it a little bit more intelligent.
Comment 10 Matt Rogers 2004-01-16 04:51:16 UTC

*** This bug has been marked as a duplicate of 70777 ***
Comment 11 Matt Rogers 2004-01-16 17:07:04 UTC
thiago is right, this really isn't a duplicate.
Comment 12 Matt Rogers 2004-01-18 04:53:52 UTC
from 70777: it was a KExtendedSocket misfeature: a buffered socket can block. Easily solved with setBlockingMode(false).

Testing fix now.
Comment 13 Matt Rogers 2004-01-18 05:59:32 UTC
using setBlockingMode(false) doesn't work. Maybe I'm doing something wrong. Here's the code:

mSocket = new KExtendedSocket();
mSocket->setSocketFlags(KExtendedSocket::inetSocket | KExtendedSocket::bufferedSocket);
mSocket->setBlockingMode(false);
Comment 14 Matt Rogers 2004-01-21 05:35:55 UTC
Subject: KDE_3_2_BRANCH: kdenetwork/kopete/protocols/oscar/oscarsocket

CVS commit by mattr: 

Remove the call to setBufferSize(-1, 1024) which set the write buffer to 
1024 characters. Fixes major bug 71195

CCMAIL: 71195-done@bugs.kde.org


  M +0 -2      oscarsocket.cpp   1.166.2.4


--- kdenetwork/kopete/protocols/oscar/oscarsocket/oscarsocket.cpp  #1.166.2.3:1.166.2.4
@@ -829,6 +829,4 @@ void OscarSocket::OnBosConnect()
 {
         kdDebug(14150) << k_funcinfo << "Connected to " << socket()->host() << ", port " << socket()->port() << endl;
-        if (!socket()->setBufferSize(-1, 1024))
-                kdDebug(14150) << k_funcinfo << "Failed setting new buffersize!" << endl;
 }
 


Comment 15 Thiago Macieira 2004-01-21 17:33:43 UTC
To set a socket non-blocking, the socket must be already connected. You can't use setBlockingMode before that: it'll return false indicating error.
Comment 16 luigi zellino 2006-01-15 01:39:39 UTC
Splitting long messages causes the gpg-encryption plugin not to work anymore! 
Please fix this bug -> 119618