Bug 71195

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?

Interesting, KExtendedSocket::writeBlock is returning -1 in a buffered socket. That shouldn't happen.

not a showstopper

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.

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.

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.

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?

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. :)

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.

*** This bug has been marked as a duplicate of 70777 ***

thiago is right, this really isn't a duplicate.

from 70777: it was a KExtendedSocket misfeature: a buffered socket can block. Easily solved with setBlockingMode(false).

Testing fix now.

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);

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;
 }
 

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.

Splitting long messages causes the gpg-encryption plugin not to work anymore! 
Please fix this bug -> 119618