On Mon, Jan 23, 2006 at 01:58:10PM -0200, Jorge Merlino wrote:
> I'm using PyMSNt 0.10.3 and I have observed the following problem with the
> status of the MSN users:
> Let's say that the jabber user sends a presence message with show=away and
> status=foo. The MSN user is then away and I can see the status message. When
> the jabber user sends an empty presence message (neither show nor status) the
> MSN user becomes available but it its status message remains 'foo' while the
> user status message is empty in the jabber network.
>
> Has anyone noticed this?, is this really a bug?
I also noticed this behaviour, however, only between two Jabber users
using PyMSNt. When the transport is sending an empty personal message to
the Messenger server, it is done with an empty UBX message - the
official client, however, sends <Data><PSM></PSM>...</Data>. In itself,
this isn't an issue, however, the transport doesn't reset the personal
message when receiving such an empty UBX message.
The attached patch fixes the issue for me (and a similar situation where
the transport receives a non-empty UBX message without an PSM element).
Best regards,
Lars
-------------- next part --------------
Index: src/tlib/msn/msn.py
===================================================================
--- src/tlib/msn/msn.py (revision 99)
+++ src/tlib/msn/msn.py (working copy)
@@ -1045,16 +1045,17 @@
self.gotMSNAlert(bodytext, actionurl, subscrurl)
def _gotUBX(self, message):
+ msnContact = self.factory.contacts.getContact(message.userHandle)
+ if not msnContact: return
lm = message.message.lower()
p1 = lm.find("<psm>") + 5
p2 = lm.find("</psm>")
if p1 >= 0 and p2 >= 0:
personal = unescapeFromXml(message.message[p1:p2])
- msnContact = self.factory.contacts.getContact(message.userHandle)
- if not msnContact: return
msnContact.personal = personal
self.contactPersonalChanged(message.userHandle, personal)
else:
+ msnContact.personal = personal
self.contactPersonalChanged(message.userHandle, '')
def checkMessage(self, message):
@@ -1368,6 +1369,9 @@
self.currentMessage = MSNMessage(length=messageLen,
userHandle=params[0], screenName="UBX", specialMessage=True)
self.setRawMode()
else:
+ msnContact = self.factory.contacts.getContact(params[0])
+ if not msnContact: return
+ msnContact.personal = ''
self.contactPersonalChanged(params[0], '')
def handle_UUX(self, params):
From [EMAIL PROTECTED] Tue Jan 24 16:39:33 2006
From: [EMAIL PROTECTED] (Lars T. Mikkelsen)
Date: Tue Jan 24 16:39:40 2006
Subject: [py-transports] PyMSNt and Google Talk
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
I've updated the patches a bit. The handling of presence probes is moved
to session.py (I think this is cleaner) and it now supports presence
probes to the transport itself. The webreg application now actually
imports the legacy users when used with a Google Talk account.
Best regards,
Lars
On Sat, Jan 21, 2006 at 08:55:51PM +0100, Lars T. Mikkelsen wrote:
> I've been doing some testing of using PyMSNt from Google Talk.
> Unfortunately, things are not running as smooth as one could hope for:
>
> 1) Sometimes contacts are unsubscribed, apparently by the Google Talk
> server. I think this is related to the issue discussed on the jadmin
> list [1].
>
> 2) When the mouse is hovered over a contact in the Google Talk client,
> the client sends a presence probe (i.e. <presence type="probe"
> to="[EMAIL PROTECTED]"/>). If the client doesn't receive presence from
> the contact within a few seconds, the status of the contact is changed
> to offline. I'm a bit unsure if the Google Talk client is violating
> RFC3921 by sending these presence probes. RFC3921 states:
>
> o probe -- A request for an entity's current presence; SHOULD be
> generated only by a server on behalf of a user.
>
> As I'm interpreting this only servers are allowed to generate presence
> probes. In any case, however, I think PyMSNt should be able to respond
> to presence probes. A patch to fix this is attached (the patch is a
> quick hack, I guess it could be made cleaner).
>
> 3) The webreg application doesn't support DNS SRV as required for Google
> Talk. A patch to add support for DNS SRV is attached. It uses
> dns_get_record(), so it will only work with PHP5 - hence, I also added
> fallback to a list of known servers. Furthermore, the patch changes a
> couple of '<?' to '<?php'.
>
> Best regards,
> Lars
-------------- next part --------------
Index: src/session.py
===================================================================
--- src/session.py (revision 99)
+++ src/session.py (working copy)
@@ -270,7 +270,12 @@
def handleResourcePresence(self, source, resource, to, tor, priority,
ptype, show, status):
- if ptype and ptype != "unavailable": return # Ignore presence
errors, probes, etc
+ if ptype and ptype.startswith("probe"):
+ if to.find('@') > 0:
+
self.contactList.getContact(to).sendPresence(source)
+ else:
+ self.legacycon._sendShowStatus()
+ if ptype and ptype != "unavailable": return # Ignore presence
errors, etc
if to.find('@') > 0: return # Ignore presence packets sent to
users
existing = self.resourceList.has_key(resource)
-------------- next part --------------
diff -ur webreg-0.4.orig/doregister.php webreg-0.4/doregister.php
--- webreg-0.4.orig/doregister.php 2005-06-13 04:03:29.000000000 +0200
+++ webreg-0.4/doregister.php 2006-01-24 16:38:25.000000000 +0100
@@ -29,6 +29,34 @@
require("class.jabber.php");
+class SRVConnector extends CJP_StandardConnector {
+ function OpenSocket($server, $port) {
+ if (function_exists("dns_get_record")) {
+ $record = dns_get_record("_xmpp-client._tcp.$server",
DNS_SRV);
+ if (!empty($record)) {
+ $server = $record[0]["target"];
+ $port = $record[0]["port"];
+ }
+ } else {
+ switch ($server) {
+ case "gmail.com":
+ $server = "talk.google.com";
+ break;
+ }
+ }
+
+ if (($this->active_socket = @fsockopen("tls://$server", $port))
+ || ($this->active_socket = @fsockopen("ssl://$server",
$port + 1))
+ || ($this->active_socket = @fsockopen($server, $port)))
{
+ socket_set_blocking($this->active_socket, 0);
+ socket_set_timeout($this->active_socket, 31536000);
+
+ return TRUE;
+ } else {
+ return FALSE;
+ }
+ }
+}
// Globals
$tmp = explode("@", $_POST['jid']);
@@ -59,8 +87,15 @@
$JABBER->password = $jpassword;
$JABBER->resource = "TransportRegister";
//$JABBER->enable_logging = TRUE;
+// Increase the sleep timer slightly to make it more likely to pass S2S
+$JABBER->iq_sleep_timer = 4;
+$JABBER->connection_class = "SRVConnector";
$JABBER->Connect() or die("Couldn't connect to your Jabber server. Please
check your Jabber ID.");
$JABBER->SendAuth() or die("Couldn't authenticate with your Jabber server.
Please check your Jabber ID and Jabber password.");
+// To receive subscription requests request the roster (RFC 3921, Section 8.1)
+$JABBER->SendPacket("<iq type='get'><query xmlns='jabber:iq:roster'/></iq>");
+// Don't use Jabber::RosterUpdate as it doesn't handle the absence of groups
+// $JABBER->RosterUpdate();
$JABBER->SendPresence(NULL, NULL, NULL, NULL, 1000);
Fprint("Connected!");
@@ -256,6 +291,12 @@
}
+// Jabber::RosterUpdate doesn't handle the absence of groups, so prevent it
+// from being called
+function Handler_presence_subscribed($packet) {
+
+}
+
function Handler_iq_jabber_iq_roster($packet) {
}
diff -ur webreg-0.4.orig/form.php webreg-0.4/form.php
--- webreg-0.4.orig/form.php 2005-05-29 02:19:00.000000000 +0200
+++ webreg-0.4/form.php 2006-01-21 19:52:45.000000000 +0100
@@ -10,7 +10,7 @@
<td><label for="gatewaytype">Service:</label></td>
<td>
<select id="gatewaytype" name="gatewaytype">
-<?
+<?php
foreach($gateways as $gwname => $jid) {
$gwnameu = strtoupper($gwname);
print "<option value='$gwname'>$gwnameu</option>\n";
diff -ur webreg-0.4.orig/index.php webreg-0.4/index.php
--- webreg-0.4.orig/index.php 2005-05-29 02:19:03.000000000 +0200
+++ webreg-0.4/index.php 2006-01-21 19:52:45.000000000 +0100
@@ -16,7 +16,7 @@
<hr>
-<?
+<?php
include("form.php");
?>
diff -ur webreg-0.4.orig/register.php webreg-0.4/register.php
--- webreg-0.4.orig/register.php 2005-05-29 02:19:03.000000000 +0200
+++ webreg-0.4/register.php 2006-01-21 19:52:45.000000000 +0100
@@ -10,7 +10,7 @@
<h1 class="registering">Jabber Transport Registration</h1>
-<?
+<?php
include("doregister.php");
?>
From [EMAIL PROTECTED] Tue Jan 24 16:49:20 2006
From: [EMAIL PROTECTED] (Alexey Nezhdanov)
Date: Tue Jan 24 16:49:28 2006
Subject: [py-transports] delays in pyAIM-t and pyICQ-t
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
? ????????? ?? ??????? 24 ?????? 2006 17:27 Daniel Henninger ???????(a):
> I'm not really sure what to tell ya. Anyone else run into this? All
> I can really say is that it's "not happening to me" and that I can't
> tell what would be causing it. Have you tried restarting PyAIM/PyICQ?
Yes, have restarted it. I ever had run it on different boxes (that were
located in different countries ever).
Though on seconds server delivering messages was actually quicker (though not
perfect). May be just not to good connections in both cases?..
> Daniel
>
> On Jan 24, 2006, at 8:42 AM, Alexey Nezhdanov wrote:
> > ? ????????? ?? ??????? 24 ?????? 2006 15:27
> >
> > Daniel Henninger ???????(a):
> >> How long has this been going on? I've noticed this in the following
> >> situations . . .
> >
> > It beginned about 24 hours back from now.
> >
> >> 1. In what seems like the AIM/ICQ servers have rate limited my
> >> server . . . I don't know that that's what's going on, but during
> >> these periods I seem to be able to get the same performance from a
> >> real AIM client and if I just connect from a different ip address
> >> everything is fine all of a sudden
> >
> > I have tried connecting with gaim from the same ip and it worked
> > instantly w/o
> > any delays. At the same time I have tried using pyAIM-t and pyICQ-t
> > from
> > another completely different IP and it was experiencing less but
> > similar
> > delays.
> > Though this second IP is used for connecting 1000+ ICQ users and
> > one AIM
> > user...
> >
> >> 2. Something was going on with my network connection at the time
> >> 3. I had switched to Jive Messenger, which seemed to periodically do
> >> this for no good reason what-so-ever
> >> 4. Machine I was running PyICQ/PyAIM on was bogged down for some odd
> >> reason.
> >>
> >> That said, I'm definitely not seeing this behavior now. =/
> >>
> >> Daniel
> >>
> >> On Jan 24, 2006, at 1:40 AM, Alexey Nezhdanov wrote:
> >>> Hello.
> >>> I have noticed that recently these two transports began to deliver
> >>> messages
> >>> very slowly. Actually ICQ delay someimes reaches 60 seconds, and
> >>> usually
> >>> about 30-40 seconds. AIM delays is one degree less and variates in
> >>> interval
> >>> 5-20 seconds.
> >>>
> >>> Is anybody seeing the same behaviour with these transports?
--
Respectfully
Alexey Nezhdanov
