Here I describe actually two bugs. One bug is obvious - pyMSN-t replies with type='subscribed' too fast and second may be not so easy to catch - account going offline for some reason.
Here is example of this: two contacts, one registered in pyMSN-t and other one logged in in GAIM trying to chat with each other. pyMSN-t accont is operating by script, GAIM operated by human. All packets going there and here very fast, I didn't measured, that may be pretty about 0.1-0.2 second. 1) script sends subscription request to gaim and waits for subscription approval by gaim <presence from='[EMAIL PROTECTED]' to='[EMAIL PROTECTED]' type='subscribe' id='117'/> 2) (First bug) pyMSN-t immidiatedly sends back subscription approval <presence to='[EMAIL PROTECTED]' from='[EMAIL PROTECTED]' type='subscribed'/> 3) pyMSN-t notifies that other party is offline <presence to='[EMAIL PROTECTED]' from='[EMAIL PROTECTED]/msn' type='unavailable' /> 4) script ignores "user is offline" presence and sends a message <message from='[EMAIL PROTECTED]/reply' to='[EMAIL PROTECTED]' id='119'><body>test</body></message> 5) scrpt deletes newly-added contact from roster <presence from='[EMAIL PROTECTED]' to='[EMAIL PROTECTED]' type='unsubscribe'/> 6) (second bug) account suddenly going offline <presence to='[EMAIL PROTECTED]' from='msn.localhost' type='unavailable'/> Obviously second bug is triggered by way too fast stanzas coming in: subscribe+message+unsubscribe. Though transport still better should stand it IMHO. -- Respectfully Alexey Nezhdanov
