Gtalk and code progress report...
We have looked at the xml bouncing back and forth in Jabber. We have looked a lot on the xml between the jabbin client and the gtalk.google.com server(s). We needed to reverse engineer the GTalk jingle protocol, since we can not find it on the Internet. As mentioned in a previous post, Jabbin has a nice XML console feature, which is VERY usefull to us - both for testing stanzas and for seeing what is actually happening in the protocol.
But we have had some problems reproducing the XML bouncing due to a "weird" HEX number on the Jabber resource which only appears in Gaim/Pidgin and not in Jabbin.
We sought advice in the Jabber developer channel, and found that it was the google server that appended this hex number to the resource - depending on the authorization. This is the actual chat:
(11:31:30) tdh1976: Hi there, any1 who is a little familiar with the jabber implementation in Gaim/Pidgin?
(11:31:31) Alex left the room.
(11:32:58) tdh1976: Its because a number is append to the resource when we log on to the gtalk server using Gaim... and we really dont understand it!
(11:33:42) Asterix: tdh1976, it's not gaim, it's gtalk itself
(11:33:50) Spike: I think it's called "Resource binding".
(11:34:12) Asterix: in fact when a client connect, it requests a resourc, and the server return the resource it must use. gtalk adds a number at the end ... don't ask why ...
(11:42:23) tdh1976: why? :P
(11:42:51) tdh1976: we have been looking at jabbin and gaim and it is not there in jabbin
(11:44:08) Asterix: maybe jabbin shows the resource the user gave, but it's not the one used in gtalk server
(11:44:30) tdh1976: hmm ok that helped us a little. thx guys
(11:46:10) legoscia: hm¡Ä does gtalk add the number when the client uses legacy authentication? that seems hard to me¡Ä
(11:46:33) Kev: Jabbin is a fork of Psi before 0.10
(11:46:53) Kev: so it does legacy auth instead of sasl and so not resource binding
(11:47:25) Kev: and yes, google assigns the hex resources if the client supports resource binding and doesn't otherwise
(11:47:34) Kev: (and yes, that sounds pretty hard)
(11:47:48) tdh1976: but then again it explains a lot ;-)
(11:48:50) Alex entered the room.
(11:49:44) Alex: morning guys
(11:50:14) Kev: morning Alex
(11:52:00) Kev: (the reason for the hex appendage to resources is so google talk can track user sessions across their server farm, I've been told (I don't know how they manage this without resource binding))
hex-ressource
Drawback in the Jabber Pidgin implementation
We have now faced the first really big problem keeping our code strictly as a plugin. This is due to the way the Jabber protocol plugin is designed in Gaim/Pidgin. It returns an error stanza because it does not understand some of the stanzas that we are going to use.
As the plugin is designed we can not hook in and intercept those packages without modifying the Jabber protocol code. So we have done that - still hoping to find a better solution later on.
Voicenode object:
We have node started to integrate the voicenode "object" (typedef struct) that we have had in mind for some time. This is a container which should hold the needed information when parsing/generating stanzas.
Code status resume:
We have now made code that can send a range of different stanzas. We have done a good start on the iq-stanza parser which we will next develop further. We hope to see some ping-pong communication soon...
But we have had some problems reproducing the XML bouncing due to a "weird" HEX number on the Jabber resource which only appears in Gaim/Pidgin and not in Jabbin.
We sought advice in the Jabber developer channel, and found that it was the google server that appended this hex number to the resource - depending on the authorization. This is the actual chat:
(11:31:30) tdh1976: Hi there, any1 who is a little familiar with the jabber implementation in Gaim/Pidgin?
(11:31:31) Alex left the room.
(11:32:58) tdh1976: Its because a number is append to the resource when we log on to the gtalk server using Gaim... and we really dont understand it!
(11:33:42) Asterix: tdh1976, it's not gaim, it's gtalk itself
(11:33:50) Spike: I think it's called "Resource binding".
(11:34:12) Asterix: in fact when a client connect, it requests a resourc, and the server return the resource it must use. gtalk adds a number at the end ... don't ask why ...
(11:42:23) tdh1976: why? :P
(11:42:51) tdh1976: we have been looking at jabbin and gaim and it is not there in jabbin
(11:44:08) Asterix: maybe jabbin shows the resource the user gave, but it's not the one used in gtalk server
(11:44:30) tdh1976: hmm ok that helped us a little. thx guys
(11:46:10) legoscia: hm¡Ä does gtalk add the number when the client uses legacy authentication? that seems hard to me¡Ä
(11:46:33) Kev: Jabbin is a fork of Psi before 0.10
(11:46:53) Kev: so it does legacy auth instead of sasl and so not resource binding
(11:47:25) Kev: and yes, google assigns the hex resources if the client supports resource binding and doesn't otherwise
(11:47:34) Kev: (and yes, that sounds pretty hard)
(11:47:48) tdh1976: but then again it explains a lot ;-)
(11:48:50) Alex entered the room.
(11:49:44) Alex: morning guys
(11:50:14) Kev: morning Alex
(11:52:00) Kev: (the reason for the hex appendage to resources is so google talk can track user sessions across their server farm, I've been told (I don't know how they manage this without resource binding))
hex-ressource
Drawback in the Jabber Pidgin implementation
As the plugin is designed we can not hook in and intercept those packages without modifying the Jabber protocol code. So we have done that - still hoping to find a better solution later on.
Voicenode object:
We have node started to integrate the voicenode "object" (typedef struct) that we have had in mind for some time. This is a container which should hold the needed information when parsing/generating stanzas.
Code status resume:
We have now made code that can send a range of different stanzas. We have done a good start on the iq-stanza parser which we will next develop further. We hope to see some ping-pong communication soon...
Labels: gtalk hex ressource
0 Comments:
Post a Comment
<< Home