On 12/6/05, Eric Langheinrich <[EMAIL PROTECTED]> wrote: > Tcpdump shows traffic that looks okay. > > I'm not writing out a separate jabber-router.log file, but maybe that's > something I'll change today. Right now everything is going to syslog. Output > looks like > > Dec 6 11:11:20 mail jabberd/c2s[5935]: [8] [X.X.X.X, port=2298] connect > Dec 6 11:11:22 mail jabberd/c2s[5935]: [8] SASL authentication succeeded: > mechanism=DIGEST-MD5; [EMAIL PROTECTED] > Dec 6 11:11:22 mail jabberd/c2s[5935]: [8] bound: > [EMAIL PROTECTED]/Exodus > Dec 6 11:11:22 mail jabberd/c2s[5935]: [8] requesting session: > [EMAIL PROTECTED]/Exodus > Dec 6 11:11:22 mail jabberd/sm[5933]: session started: > [EMAIL PROTECTED]/Exodus > Dec 6 11:12:07 mail jabberd/resolver[5932]: [aim.mydomain.org] resolved to > [X.X.X.X:5269] (86400 seconds to live) > Dec 6 11:13:17 mail jabberd/c2s[5935]: [8] [X.X.X.X, port=2298] disconnect > Dec 6 11:13:17 mail jabberd/sm[5933]: session ended: > [EMAIL PROTECTED]/Exodus >
This is the output from when you logged in using a client jabbberd/c2s. See if you can find some from the router: jabberd/router. > I'm a little confused about the aim gateway being resolved. But that could > just be my ignorance. That was because you logged in, it's trying to look for the aim gateway on your server, that's all good. > Do I need to make any changes to the jabber xml files aside from adding the > following to the router.xml file? > > <!-- These users can bind names other than their username --> > <acl type='bind'> > <user>pyaimt_user</user> > </acl> > and create the user (with password) in the router-users.xml file obviously. After you have made these changes you _MUST_ restart the jabber-router component. (basically restart the whole jabber daemon bundle) I thought that maybe you'd forgotten to set the saslUsername in your pyaimt config.xml to 'pyaimt_user', or you haven't enabled useJ2Component. But the debug log shows that those are set correctly. See if you can get a tcpdump of traffic on port 5347 on the localhost interface as you start the transport. -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/ From [EMAIL PROTECTED] Tue Dec 6 19:23:55 2005 From: [EMAIL PROTECTED] (Norman Rasmussen) Date: Tue Dec 6 19:24:03 2005 Subject: [py-transports] PyMSN-t avtar hash In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> On 12/6/05, Pedro Melo <[EMAIL PROTECTED]> wrote: > On Dec 6, 2005, at 6:09 PM, Norman Rasmussen wrote: > > The whole point of using the hash is it's a global fingerprint of the > > file. If one user used sha1 and another user used xyz, then they > > might generate the same hash for seperate files. What's the client > > supposed to do then? Store one image per roster item? > > No, the only thing you can get from the hash is the fact the I sent > you an hash of X and then I sent you an hash of Y. That means that my > image as changed. Okay. > If *all* the client behave and implement correctly the protocol, you > can then assume that the hash of the binary representation of the > image is the hash sent in the presence stanza. As we can see from > this thread, some clients don't behave correctly. one client doesn't. > The question of local storage is totally unrelated. By all means hash > each image that you get and store them per hash, so that images with > the same hash are stored only once. yes, store the image once, index it by hash - e.g. filename is the sha1 hash of the image data. > My only point in the whole thread is this: if you use the hash only > as a signal that the avatar has changed, you'll have a better client > in the sense that it will work no matter what other clients/servers do. and when 300 people on your list (perhaps msn transport users) change their avatar all at once (like when the transport is upgraded). All their hashes change from 'xxx' to 'yyy', and you retrieve _all_ of the vcard just in case their hashs are different. Remember you can't map the 'reported' hash to your filesystem store, because it might not be the true hash of the file. The whole point of sending the hash is so that the client doesn't re-download an image it _knows_ it already has. -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/ From [EMAIL PROTECTED] Tue Dec 6 23:26:04 2005 From: [EMAIL PROTECTED] (Oscar =?ISO-8859-1?Q?Hellstr=F6m?=) Date: Tue Dec 6 23:26:16 2005 Subject: [py-transports] PyMSN-t avtar hash In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> On Tue, 2005-12-06 at 21:23 +0200, Norman Rasmussen wrote: > On 12/6/05, Pedro Melo <[EMAIL PROTECTED]> wrote: > > On Dec 6, 2005, at 6:09 PM, Norman Rasmussen wrote: <snip> > > If *all* the client behave and implement correctly the protocol, you > > can then assume that the hash of the binary representation of the > > image is the hash sent in the presence stanza. As we can see from > > this thread, some clients don't behave correctly. > one client doesn't. And that was in during development. I just wanted the issue to be discussed here, since avatar is kinda hot here :) However, it seems the right thing to do is to push for clarification of the involved JEP:s, to make them reflect what is really implemented (it is an historical JEP isn't it). Then new clients, or clients who develops avatar support, can do it according to the JEP and behave as expected. Anyway, isn't it usually the server which stores the avatar and calculates the hash? Or is the hash given to the server? I am not talking about transports here. In that case, there aren't that many implementations that can misbehave. I am one of those who don't believe in using my time make my applications cope with misbehaving applications. <snip> > -- > - Norman Rasmussen > - Email: [EMAIL PROTECTED] > - Home page: http://norman.rasmussen.co.za/ > _______________________________________________ > py-transports mailing list > [email protected] > http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports -- Oscar Hellstr?m, [EMAIL PROTECTED] web: personal.oscarh.net jid: [EMAIL PROTECTED] icq: 52604556 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://modevia.com/pipermail/py-transports/attachments/20051207/671644e3/attachment.pgp From [EMAIL PROTECTED] Tue Dec 6 23:56:18 2005 From: [EMAIL PROTECTED] (Trejkaz) Date: Tue Dec 6 23:57:07 2005 Subject: [py-transports] PyMSN-t avtar hash In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> >> My only point in the whole thread is this: if you use the hash only >> as a signal that the avatar has changed, you'll have a better client >> in the sense that it will work no matter what other clients/servers do. > and when 300 people on your list (perhaps msn transport users) change > their avatar all at once (like when the transport is upgraded). All > their hashes change from 'xxx' to 'yyy', and you retrieve _all_ of the > vcard just in case their hashs are different. Remember you can't map > the 'reported' hash to your filesystem store, because it might not be > the true hash of the file. > > The whole point of sending the hash is so that the client doesn't > re-download an image it _knows_ it already has. Exactly. If we only wanted to know that the avatar changed, the protocol wouldn't require an actual hash in the first placel it could just start at 1 and increment every time the avatar changes. TX
