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> Table "pglogd.log_entries"<br> Column | Type | Modifiers | Description<br>------------------+--------------------------+-----------+-------------<br> request_time | timestamp with time zone | |<br> seconds_to_serve | integer | |<br> response_code | integer | |<br> bytes_sent | integer | |<br> request_type | character varying(10) | |<br> virtual_domain | character varying(80) | |<br> remote_host | character varying(80) | |<br> request_url_path | character varying(80) | |<br> referer | text | |<br> user_agent | text | |<br> request | text | |<br> logname | character varying(30) | |<br> username | character varying(30) | |<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
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