Re: [jdev] Best ways for a JID to advertise what services it uses?
On Fri, 8 Oct 2010, Sergey Dobrov wrote: On 09/21/2010 09:15 PM, Dave Cridland wrote: On Tue Sep 21 14:34:54 2010, Stephen Pendleton wrote: Right, and the ideal answer is to use PEP - or rather, pubsub-onna-jid. PEP has another restriction, there are can't be more than one publisher. I'm missing the language in the XEP which limits a given node to only having one publisher at a time. I do see where a given item has only one publisher though. This makes impossible to build some kinds of applications on it. How so? -- Bruce. ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Best ways for a JID to advertise what services it uses?
On Sat, 9 Oct 2010, Sergey Dobrov wrote: On 10/09/2010 02:05 AM, Bruce Campbell wrote: On Fri, 8 Oct 2010, Sergey Dobrov wrote: On 09/21/2010 09:15 PM, Dave Cridland wrote: On Tue Sep 21 14:34:54 2010, Stephen Pendleton wrote: Right, and the ideal answer is to use PEP - or rather, pubsub-onna-jid. PEP has another restriction, there are can't be more than one publisher. I'm missing the language in the XEP which limits a given node to only having one publisher at a time. I do see where a given item has only one publisher though. I don't really understood you but this is explaining link: http://xmpp.org/extensions/xep-0163.html#approach-publisher The option of having multiple publishers per node is covered under the following: : A PEP service MAY support other use cases, affiliations, access models, : and features, but such support is OPTIONAL. ( http://xmpp.org/extensions/xep-0163.html#defaults ) This makes impossible to build some kinds of applications on it. How so? For example if I want to do the service with friends feedbacks about user. Then I need to allow other users to publish to a node. Similar to a user's 'wall' in facebook. Its possible. -- Bruce. ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Best ways for a JID to advertise what services it uses?
On Thu, 7 Oct 2010, Sergey Dobrov wrote: On 10/07/2010 03:13 AM, Matthew Wild wrote: It occured to me that this issue actually relates to a recurring problem we have in XMPP. When an account is removed from a server we remove subscriptions to their contacts also. Unfortunately there is no standard way to know what services an account may have also been associated with, and so no way to notify them of the accounts deletion. But what about transports? It's not enough to remove subscription on them. We need to unregister also. Otherwise a new JID's owner will be allowed to access old owner's legacy accounts... Account re-use is more of a political problem (ie, do the server administrators prevent re-use of a given account name for all time, or allow it to be used after a certain period ) than a protocol problem. One way to address it would be to 'suggest' that administrators don't re-use a given account for a given period, and for everything that has subscriptions to peridocially re-verify all subscribers in some manner. Ugh. -- Bruce. ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] Embedding a XMPP stream within an IMAP stream, thoughts?
On Fri, 18 Jun 2010, Dave Cridland wrote: On Fri Jun 18 18:46:51 2010, Kurt Zeilenga wrote: On Jun 18, 2010, at 3:32 AM, Dave Cridland wrote: A least abomination method for this would be to have a new protocol which acted as a multiplex and single authenticator, and then you could have that use proxy-auth to handle the connect/authenticate cycles of both IMAP and XMPP (and others). BEEP? :-) The worst thing about that is it actually makes quite a bit of sense. Huh, I'd completely forgotten all about BEEP. That might also work quite well. -- Bruce. ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
[jdev] Embedding a XMPP stream within an IMAP stream, thoughts?
This is an odd idea that I'm mulling over as part of the creation of a user interface (email and IM) within a limited connectivity-but-controlled environment. Essentially, creating connections is expensive, and both IMAP and XMPP user credentials are the same. Think BOSH within a pre-existing IMAP stream. So far I've got a set of draft notes which amount to creating a new IMAP capability 'XMPP', a group of client subcommands to control XMPP connection/disconnection/multiple identities/sending stanzas, and the facility for the server to send arbitary stanzas via untagged responses, along with various protocol handwaving to keep things nice and neat. Any thoughts on the concept and suggestions as to whether to raise this as a XEP here or within the appropriate IETF group (Lemonade I believe) ? -- Bruce. ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] When to pass the JID??
On Fri, 21 May 2010, Mason, Matt wrote: Reading through the spec http://www.ietf.org/rfc/rfc3920.txt on the bottom of page 17, top of 18 shows a basic session. In my implementation I am trying to figure out when the heck to pass the JID of the client. Not in the stream. Section 3.5 of rfc3920, Determination of Addresses, is probably what you want to be reading, along with section 7, Resource Binding. -- Bruce. ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
Re: [jdev] XEP-0080: adding location source information
On Fri, 2 Apr 2010, Peter Saint-Andre wrote: On 2/23/10 9:03 AM, Kyle Usbeck wrote: I very strongly support the addition of source and provider information to the geoloc spec, Great. Patches welcome. :) but their addition means that we might also have to modify the way we represent stop commands. According to XEP-0080: In order to indicate that the user is no longer publishing any location information, the user's client shall send an empty geoloc/ element, which can be considered a stop command for geolocation. Example Use Case: Transmit a stop command for a WIFI source, but continue sending information from a GPS source. The stop command indicates that the entity has stopped all publishing of geolocation data from all sources and providers. The options are 1) include source and provider as optional attributes of the geoloc/ element, or 2) alter the representation of the stop command. By including the source and provider as optional attributes of geoloc/, we can continue using an empty geoloc/ as a stop command: geoloc xmlns='http://jabber.org/protocol/geoloc' http://www.google.com/url?sa=Dq=http://jabber.org/protocol/geoloc%27usg=AFQjCNEeMfdwnaV7yu2Aqox0OVKaz2IXlw xml:lang='en' source='wifi'/ I prefer, though, altering the representation by adding an explicit termination, such as the type='stop' below: geoloc xmlns='http://jabber.org/protocol/geoloc' http://www.google.com/url?sa=Dq=http://jabber.org/protocol/geoloc%27usg=AFQjCNEeMfdwnaV7yu2Aqox0OVKaz2IXlw xml:lang='en' type='stop' sourcewifi/source /geoloc I'd keep using the source/ child elements for consistency with publishing the source of the location information, rather than making it a sometime attribute on geoloc/. Since the geoloc/ element would not be empty in the above case, existing implementations shouldn't be treating it as the complete end of location informations from the source user, but I guess this depends on whether 'empty' is considered by the implementation as being 'no child elements' or 'no lat/lon/usable elements'. Are there any other options that I'm missing? Why do you need to indicate that you are stopping publication from a particular source or provider? Is there a use case for that feature? I've got two mildly-contrived-but-plausible use cases. Firstly, say that your device is being used to feed location information (GPS and Intertial) to a subscriber which is providing you with real-time driving directions. As you enter an extended tunnel, the GPS source loses its signal lock, and at the next publication interval, sends a stop stanza for that source. This lets the real-time driving directions supplier know that you are where you should be (ie, in the tunnel, and not on the surface street), and to fall back on timed directions based on the information from the Inertial source. Second use case, say that the same device is actually receiving detailed Inertial information via a bluetooth connection to the vehicle. As you park in the parking lot and turn off your vehicle, that source goes away and a stop stanza for that source is generated. A subscriber notices the disconnection of that particular source, and records your last-received location for later use when you press the ``dude, where's my car?'' button on the device. -- Bruce. ___ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org ___
[jdev] That presence problem again
This more of a 'what are people doing now' question, not a 'what should the implementations be doing'. Lets say that my Jabber client has an avid desire to know the accurate online status of remote JIDs, and the roster subscriptions are 'both'. To that end, my client makes the assumption that if no update to the status has been received in an hour, then something has possibly happened to the remote JID that hasn't been properly pushed to my client (remote server restart normally ). How should my Jabber _client_ get the latest news about the remote JID? The solutions that I've tried to get this information are: A) Presence probes. Swallowed by some servers. presence to='[EMAIL PROTECTED]' type='probe'/ or presence to='[EMAIL PROTECTED]' from='[EMAIL PROTECTED]' type='probe'/ B) Directed presence saying unavailable then available again. presence to='[EMAIL PROTECTED]' type='unavailable'/ presence to='[EMAIL PROTECTED]'/ C) Subscribe to their presence again. presence to='[EMAIL PROTECTED]' type='subscribe'/ and finally (this far less frequently than anything directed at a given JID): D) Unavailable then available again to the entire roster. presence type='unavailable/presence/ Of these, the 'subscribe' trick seems to be the most consistent at returning the desired information. 'probe's seem to get swallowed by a number of servers, and appearing to go offline and online again just irritates the remote users. Any other tricks that people use? -- Bruce Campbell.
Re: [jdev] That presence problem again
On Sat, 21 Apr 2007, Robin Redeker wrote: On Fri, Apr 20, 2007 at 10:22:33PM +, Nathan Fritz wrote: I don't see this as being the client's job. [.snip.] I don't believe that the client should take it upon itself to nag about presence, as presence is high traffic enough as it is. I indeed agree with that. Having clients polling is very undesireable w.r.t. bandwidth and traffic. Either I could treat the existing presence push mechanism as being partially broken, poll occasionally, and have reasonably updated information and, or I could rely completely on the existing presence push mechanism, and deal with complaints of, say, a mail notification bot filling up an offline message store, or a pretty web presence bot giving the wrong information for hours on end. In this particular situation (mail notification bot), I personally prefer the fewer complaints option, since the poll traffic isn't leaving the local server. I like the iq/ option that JD supplied. -- Bruce Campbell. Of course, I'll argue the other way when it comes to chat clients ;)
Re: [jdev] Re: XMPP Ping method?
On Wed, 1 Nov 2006, Tomasz Sterna wrote: On 11/1/06, Alexander Gnauck [EMAIL PROTECTED] wrote: for some devices it's not. If you work with wireless devices (WLAN, GSM, UMTS) you will see lot's of strange behavior. Isn't that broken TCP implementation then? No; it reflects the design of TCP being based around reliable connections where interruptions were infrequent and short in duration (or permanently long). With the advent of new underlying medias which suffer from frequent interruptions of highly variable durations, the default TCP values do not cope as well. I'd imagine that certain embedded wireless devices tightly couple the TCP retransmission to the underlying carrier detection. However, many devices, for example my laptop, do not have such a tight coupling (if at all) and must rely on the TCP retransmission coinciding with the wireless card having a reliable signal to the base station. You can change the client, but asking the server to do so is not the solution. -- Bruce Campbell.
Re: [jdev] XMPP Ping method?
On Wed, Nov 01, 2006 at 06:07:39PM +0100, Tobias Markmann wrote: Isn't that a TCP problem since that can happen to any protocol which is based to TCP? You should diffentiate between interactive and bulk protocols that use TCP. The latter tend towards getting as much data in the shortest amount of time (eg HTTP and FTP request - response setup), whilst the former (telnet/ssh, xmpp etc) tend to small amounts of data being sent at arbitary intervals. On Wed, 1 Nov 2006, Dave Cridland wrote: Hop-by-hop tests are quite easy, too, but there's a gotcha - when they fail, you want to know which stanzas you need to resend. And XMPP does not provide any mechanism for that, and nor do pings. If you can be assured of whitespace pings between the client and the server, the server can simply queue up all stanzas as received and forwarded, and delete from the queue any stanzas sent between successful receipt of whitespace pings. Without protocol changes, the odd duplicated stanza is probably the best of a known evil. -- Bruce Campbell.
Re: [jdev] net::jabber connect w/ srv dns
On Thu, 13 Jul 2006, Gabriel Millerd wrote: You will need to do the SRV lookups yourself in order to hand Net::Jabber a hostname, either via Net::DNS (requiring you to know how SRV records work), or Net::RULI (interface to extra library, but hands you the results on a platter). Thanks for replying. I can resolve the actual _xmpp-client._tcp myself (worse case I could statically code it). But it seems that I am still left with 'hostname,port,username,passwd,resource' for my options. And username automatically becomes [EMAIL PROTECTED] I cannot supply a realm or it wont auth. Ah (realisation dawns). There is an undocumented 'componentname' variable that you can pass to Net::Jabber::Client-Connect() (actually Net::XMPP::Connection via Net::XMPP::Client) which will do what you want it to do. -- Bruce Campbell
Re: [jdev] net::jabber connect w/ srv dns
On Wed, 12 Jul 2006, Gabriel Millerd wrote: Recently my server addressing has changed somewhat. Now its location is srv based and the actual host doesn't match the realm. Because of this I am unable to get anything to work in net::jabber or the perl interface to loudmoth. Though once change to my /etc/hosts gets me in the door. I cannot really do that sadly. Is there a way around this? You will need to do the SRV lookups yourself in order to hand Net::Jabber a hostname, either via Net::DNS (requiring you to know how SRV records work), or Net::RULI (interface to extra library, but hands you the results on a platter). I'd point at the -resolve routine of Jabber::Lite (perl-only Jabber parser/whathaveyou), but thats just blatant self-promotion ;) -- Bruce Campbell
Re: [jdev] XMPP Ping/Keepalive: Recommended method ?
On Tue, 27 Jun 2006, Joe Hildebrand wrote: Date: Tue, 27 Jun 2006 05:59:54 -0600 From: Joe Hildebrand [EMAIL PROTECTED] Reply-To: Jabber software development list jdev@jabber.org To: Jabber software development list jdev@jabber.org Subject: Re: [jdev] XMPP Ping/Keepalive: Recommended method ? On Jun 27, 2006, at 4:09 AM, Bruce Campbell wrote: Well, not really. You'll get a TCP ack back, which should be enough to keep the lights on. Not if you are dealing with inspection-type firewalls which don't really treat a TCP ACK as a data packet. If firewalls did this, TCP would *break* for all applications. Can you please give a concrete example of a firewall that has this property? Not a firewall appliance, but 'interesting' configurations with ISPs seeking to keep their dial-up lines/wavelan channels free (timers on their end were only reset on certain types of packets, which did not include tcp acks). -- Bruce Campbell
Re: [jdev] XMPP Ping/Keepalive: Recommended method ?
On Mon, 26 Jun 2006, Joe Hildebrand wrote: On Jun 19, 2006, at 1:15 AM, Sergei Golovan wrote: The problem is that this ping is not a ping at all because it only sends data and does not expect reply. Well, not really. You'll get a TCP ack back, which should be enough to keep the lights on. Not if you are dealing with inspection-type firewalls which don't really treat a TCP ACK as a data packet. Some servers can also be configured to send space keep-alives. If both sides use this algorithm things seem to work pretty well: 1) set a timer to some amount of time, say 30 seconds 2) when the timer fires, send a space 3) whenever you send something, reset to the timer to zero 4) whenever you receive something, reset the timer to zero It works to a point (being probably 95% of cases). If you have a client sending pings every 40 seconds unless first reset, and the server sending pings every 30 seconds unless first reset, the client's first ping will be the one that discovers that the packet-inspecting firewall wants to see non-TCP-ack packets. If you want to go down that path, you need two timeouts; a short one (30 seconds) to be reset each time a packet is sent or received as above, and a longer one (60 seconds) to trigger a send locally. In practice, this eventually settles down to each side sending a packet at 60 second intervals, with a roughly 30 second gap between them. Even so, this requires server-side configuration; the server may not do whitespace pings for policy reasons. this allows you to detect dead links about as quickly as possible, without increasing network traffic any more than absolutely necessary. There isn't a lot of difference between a TCP packet containing a single whitespace character, and a TCP packet containing a dummy iq/ or message/ stanza. Neither will be fragmented. A whitespace ping is less expensive on the server side, as it gets thrown out by the c2s-equivilant component, and just returns a TCP ack. Conversely, a dummy stanza will always be more expensive, as depending on the server design, it may be routed through several components to get to the sm-equivilant, then routed back and sent to the client in a second TCP-data + TCP-ack pair. However, the gain is that the client 'knows' that the server is fully functioning, and any firewalls in between which expect to see data flowing in both directions have nicely had their idle timers reset, vs the client just knowing that the TCP stream to the c2s component is still functioning. On the reverse issue, I don't think that servers should generate anything more than whitespace pings to verify an ongoing TCP stream with a client. This would require changes to most client (which are user-driven, not server driven), and generally servers want to clean up after any departed TCP streams as soon as possible. I guess the point I'm trying to make is, do you want the clients to know that their next message/ will not generate a TCP error, or do you want clients to know that their next message/, if not delivered, will come back with an undeliverable stanza ? -- Bruce Campbell
Re: [jdev] jabber aliases?
On Mon, 19 Jun 2006, Igor Goryachev wrote: On 19 Jun 2006, Tony Finch wrote: Consider what happens if I send a presence subscription request to an alias JID, and get a response from the real JID. Will my client behave sensibly? Well, I suppose you will just have a dead JID in your roster (with subscription none) in addition to the real JID. RFC3921 #8.2 step #8 explicitly states that the original server should silently drop the request in such a situation. Eg: [EMAIL PROTECTED] ---subscribe--- [EMAIL PROTECTED] This by way of aliasing gets resent to [EMAIL PROTECTED] . You then approve Tony's subscription: [EMAIL PROTECTED] ---subscribed--- [EMAIL PROTECTED] However, [EMAIL PROTECTED]'s internal roster has no knowledge of [EMAIL PROTECTED] (ie, it asked Igor.Goryachev, not Igor), and thus Tony's server immediately drops the packet without passing it to Tony's client. -- Bruce Campbell
Re: [jdev] Transport suggestions
On Tue, 23 May 2006, Norman Rasmussen wrote: On May 23, 2006, at 2:09 PM, Daniel Dura wrote: Unfortunately, that doesn't fit our use case. We are using XMPP as the communications layer for our application and want people to be able to login to their GTalk account and see their GTalk contacts On 5/23/06, Daniel Henninger wrote: For what it's worth, I've been interested in a Jabber Transport of sorts as well. I have a bazillion Jabber accounts at this point and There's a Perl XMPP transport [1] written by Bruce Campbell while we were waiting for Google to enable s2s. I haven't tried it, but I think it only allows a single registration at a time. Currently yes. Its also using the venerable Jabber::Connection library. Phycon (a buddy of mine) talks [2] about XMPP transports as 'hat racks' - providing the user the ability to login to many other xmpp accounts via a transport. (Very similar to how the pyirct transport allows you to login to many irc networks at once) Huh. Thats actually quite cool overloading the '^' character to seperate the destination JID from the proxied JID. Putting on my security hat though, it exposes the proxied JID to view in the routing information, which is not good if you are running over a hostile network. This can be worked around by also allowing an internal gateway identifier. Ok, one new version of xmppgateway coming up. -- Bruce Campbell
Re: [jdev] Re: VTD-XML version 1.6
On Sat, 20 May 2006, Jimmy Zhang wrote: 2. In the future, XML capability will get built into the network layer, but if a message is not well-formed XML, they are less likely to take advantage of those capabilities of network routers and switches, again hindering adoption I suspect you're smoking better quality drugs than I can get locally. Please read through http://en.wikipedia.org/wiki/OSI_model . Introducing XML at the 'network layer' has a huge number of complications, as XML is not a strictly-ordered protocol. It means that every device receiving such a packet must run an XML parser, in order to find out where in the packet the routing information actually is. This differs from a 'real' network layer protocol such as IP, where the routing information is located at fixed offsets within the packet, and thus, is comparitively easy to put into silicon. Within the context of Jabber, XML is simply a data format used by an Application Layer protcol formerly named 'XMPP'. -- Bruce Campbell
Re: [jdev] How to handle SRV lookups when the root domain is referenced
On Tue, 2 May 2006, Dave Cridland wrote:
On Sun Apr 30 14:16:57 2006, Bruce Campbell wrote:
Both of these documents also refer to DNS-SRV (rfc2781), which states that
if the target of the sole (successful) SRV answer is the root domain ('.'),
then 'abort'.
You mean RFC2782, which states that 'A Target of . means that the service
is decidedly not available at the domain.' - later, in the description of how
to use SRV records, it merely says 'abort'.
This means your interpretation must be correct - sort of. The server could
lookup records in _simple.example.com, for instance, if it were capable of
gatewaying to SIMPLE, but no server to server XMPP service is available.
Something that struck me over the course of today, is that although a
(sole) target of '.' means 'not available', and imho, 'stop completely',
it could be argued that since XMPP-IM encourages SRV lookup chains, it
might be permissible to continue with looking up
_im._xmpp.example.com/_pres._xmpp.example.com , depending on whether you
view generic server-to-server XMPP as being different from
message-or-presence-server-to-server XMPP.
Definitely it's wrong to resolve example.com and try randomly connecting to
it - not only wrong, but arguably illegal, since you've been explicitly told
there is no such service at the domain.
Agreed, but enforcement is another matter.
--
Bruce Campbell
[jdev] How to handle SRV lookups when the root domain is referenced
In XMPP-IM (rfc3921), the appropriate SRV name to look up for server to
server connections is '_xmpp-server._tcp.HOST', followed by
'_im._xmpp.HOST' or '_pres._xmpp.HOST', followed by '_jabber._tcp.HOST'
(if one wishes compatibility with old records) finally followed by A/
lookups for 'HOST'.
In both XMPP-CORE and XMPP-IM, the wording used is 'if the (previous)
address record resolution fails, (continue with the next resolution)'.
In DNS terms, 'fails' usually means 'if there was no positive answer'.
Both of these documents also refer to DNS-SRV (rfc2781), which states that
if the target of the sole (successful) SRV answer is the root domain
('.'), then 'abort'.
Since there appear to be two sides of the fence in what to do after
encountering the DNS-SRV 'abort', I'm interested in knowing what have
Jabber server implementors done with the following corner case, assuming
that they want to deliver a presence/ and initial message/ to a JID
@example.com :
_xmpp-server._tcp.example.com. IN SRV 0 0 5269 .
_im._xmpp.example.com. IN SRC 0 0 5269 imhandler.example.com.
_pres._xmpp.example.com.IN SRC 0 0 5269 presence.example.com.
_jabber._tcp.example.com. IN SRV 0 0 5269 jabber.example.com.
example.com.IN A192.168.1.1
jabber.example.com. IN A192.168.2.2
imhandler.example.com. IN A192.168.3.3
presence.example.com. IN A192.168.4.4
Since the lookup of _xmpp-server._tcp.example.com is successful, but
returns just one record with a target of '.', have implementors treated
this record as:
'stop attempting to look up an address for example.com',
( my personal intrepretation )
or
'fallback to looking up _im._xmpp.example.com. or
_pres._xmpp.example.com. as appropriate',
( after all, there wasn't anything with an address resulting
from the first lookup ).
or
'fallback to looking up _jabber.example.com.'
( the I haven't read XMPP-IM response ;) )
or
'stop attempting to look up SRV records and fallback to looking
up A/ for example.com'
?
Various giggle searches on this topic haven't really answered the
question, and I'm not really keen on examining source code ;)
--
Bruce Campbell.
Re: [jdev] sasl digest-response
On Sat, 22 Apr 2006, [ISO-8859-2] Asia G?siewska wrote: during digest- response. After reading RFC2831 I just don' t understand this part: passwd = *OCTET The username-value, realm-value and passwd are encoded according to the value of the charset directive. If charset=UTF-8 is present, and all the characters of either username-value or passwd are in the ISO 8859-1 character set, then it must be converted to ISO 8859-1 before being hashed. What does it mean *OCTET '*OCTET' - as many octets (bytes, 8 bits) as required for the password. and should I change everything everytime to iso 8859-1 ? The whole reference to ISO 8859-1 is to maintain compatibility with HTTP. The way it works is that for the 'username-value' and 'password' fields, you scan through the field looking for any characters that are _not_ in ISO 8859-1 . If there are no characters outside ISO 8859-1 in the field, you send that field in ISO 8859-1, assuming that the value of the 'charset' directive is 'ISO 8859-1' for that specific field. So, if you have a username of 'ez$' with a password of '¥$¢£??' (Yen Dollar Cents Pounds Francs Euro), the 'username-value' only contains characters in ISO 8859-1, and should be sent in ISO 8859-1. The 'password' contains characters outside of ISO 8859-1, and should be sent in 'UTF-8', _but_ only if the 'charset' directive is already set to 'UTF-8'. Section 8 of 2831 contains a snippet of C which will do all of this for you. -- Bruce Campbell
Re: [jdev] Using chat room as resource pool -- need advice
On Mon, 13 Feb 2006, Matthew Wilson wrote: We have a bunch of boxes (20 or so) that offer web-services to our server farm of several hundred boxes. Right now, if a box on a farm needs to connect to one of the web service boxes, it iterates through a list of all the web-service boxes, and tries to connect to each one, until it finds one that is free to handle the request. Yick. Your current selection method sucks. I'm thinking that a better model might be to create a MUC where each of the web-service boxes are persistently connected. They would use their presence attribute to indicate whether they are available or busy. I'd prefer that the clients and servers communicate through the room, rather than directly, so that I can just log the chat room and see all the transactions. I'd avoid the MUC (central dependency) and rely on Jabber servers on a few boxes to establish inter-server connections. A few questions: * Is this asinine? It depends on the application really. * Has anyone done anything like this? Yes. Code is even available[1]. Are there any hidden gotchas you discovered? Essentially, you are wanting to use Jabber as a method to select the 'most' available host. Now, whilst you can do this, and it will work, there are three gotchas: a) Jabber has high latency compared to dedicated methods: The time for each web server JID to report back its process state to the chat room/other JIDs may well be longer than the time to process the request; any such information may well be out of date. b) Jabber has high latency compared to dedicated methods: The time taken to receive the roster on each connection may well be longer than the client wishes to wait. If you do implement this, do not connect to Jabber each time you wish to find an appropriate server; maintain persistent connections and write the current 'best' choice to a known file or socket. c) Jabber is object based, not stream based: The fundamentals of Jabber are packets, and before any Jabber-processing does anything with the packet, it needs to have the full packet in its grubby little hands. Thus, sending the web request via Jabber and expecting to receive a timely reply is somewhat foolish. In the situation you have described, you would be better served by avoiding Jabber; put a web load balancer in front of your web farm. -- Bruce Campbell [1] I have proof of concept code available privately that sends received web requests via Jabber off to a master JID and waits for replies via Jabber, but the gotchas described above really kill the performance.
Re: [jdev] jabberSMTP
On Thu, 15 Dec 2005, Jon Scottorn wrote: Ok, now I don't get any errors but my jabber message is still not coming through, all I get is: 03:29:26 PM] *** jabbermail is Online [forwarding email] [03:29:26 PM] *** jabbermail is Offline Have a read through of this article: http://www.pipetree.com/jabber/mail_notify.html It might not be quite what you are looking for, but it does work. Norman Rasmussen wrote: I think this would be much cooler with a full smtp transport gateway idea, but this works for now. For the jabberd 1.4 series, there was a smtp gateway project listed at jabberstudio. Doesn't appear to be there now, but someone helpfully posted the entire tarball to the jadmin list a few days ago. -- Bruce Campbell
Re: [jdev] if anyone is having problems with slow propogation forx xmlns=MY_NAMESPACE messages...
On Wed, 30 Nov 2005, Norman Rasmussen wrote: You might also try presence elements instead of message elements - depending on what you mean by the game event. Typically I would map game movement to presence elements, and game actions via messages - thoughts? As long as its always directed presence elements (ie, with a 'to') that is being sent out. I have vague worries of such a game engine being used with a user's regular jabber credentials and annoying everyone on their roster with floods of spurious update information. Quite apart from that, its a good idea. It means that regular jabber servers can be used on the servers, and the normal availability mechanism will nicely kick when a game connection disconnects. -- Bruce Campbell [EMAIL PROTECTED]
Re: [jdev] [JEP-33] Some questions
On Tue, 29 Nov 2005, Norman Rasmussen wrote: On 11/29/05, Gaston Dombiak [EMAIL PROTECTED] wrote: I was reading JEP-33 and some questions came up to my mind. :) Are you considering that the 'server' is a standard jabber server, with no extra multicast support. There's an extra multicast component that is handling all the multicast requests. Has anyone actually implemented JEP-33 yet? Quite apart from the obvious usage cases of roster and conferencing component, I can see some situations where a s2s component might dynamically start implementing it on traffic to a remote domain. -- Bruce Campbell
Re: [jdev] Google Talk transport?
On Mon, 3 Oct 2005, Norman Rasmussen wrote: On 03/10/05, John Talbot [EMAIL PROTECTED] wrote: Norman Rasmussen wrote: I was thinking of making a general XMPP transport for jabber. You would have to register with it to supply your gtalk account details. Also when you set it up on your server you would override the @gmail.com with the transport, and then all your google talk stuff is 100% transparent to the user after he has registered. ...but why the phrase was thinking? Aren't you thinking of going ahead anymore? I'm hoping that google will enable s2s before I have time to code it :-P Doesn't look that hard. JEP 100 documents most of the cases. Actually, it wasn't that hard. You can download a simple version at http://zerlargal.org/c/xmppgateway.pl . As-is, it probably will _not_ work for realtime conversations with Google talk, but enterprising people will understand what line 191 does and be able to work around it. Known Bugs: PSI drops certain fields in the registration, Gabber doesn't. This makes registering with the gateway a touch difficult. Its a 1 to 1 mapping; a given client cannot register multiple times to different remote networks. The polling is crufty, and I wouldn't be surprised if it managed to mix up messages when gatewaying multiple users. If there are bugs beyond what is documented, I'd love to hear about them. -- Bruce Campbell Now, all I have to do is to complete my idea of having a corporate gateway relaying from [EMAIL PROTECTED] to [EMAIL PROTECTED], and I'm set.
Re: [jdev] Google Talk transport?
On Tue, 4 Oct 2005, Norman Rasmussen wrote: I'm not that up to speed with the Perl Jabber libraries, so please excuse me if I'm wrong here. When I got around to implementing a transport is going to be in python, because I'm familiar with that. I was going to make one client connection per-resource. So basically if you login twice, you proxy twice too. The way that I've handled it is to use '[EMAIL PROTECTED]' as the key for looking up stored credentials. Although changing it to use '[EMAIL PROTECTED]/resource' as the key, that approach would mean that the user would have to resupply credentials if they connect using a different resource value (perhaps this means different client, perhaps it means a different instance of the same client). Peter Saint-Andre can probably comment which is the intended approach for JEP-100. Wouldn't that get rid of the Handling of the Resource portion of the JID is at times crufty comment? The cruftyness comment is because I don't bother to copy the resource value from the requesting client to the proxied [EMAIL PROTECTED] Eg, if you start talking to the gateway as '[EMAIL PROTECTED]/Gabber', the proxied connection is '[EMAIL PROTECTED]/gateway.processid.timevalue' . Also why not move to data forms to address Certain clients silently drop some of the tags requested for registration.. That way you can make your own fields, and things will just-work(tm). I'm not sure I follow you. I'm passing from the component to the user: iq from='componentname' to='[EMAIL PROTECTED]/resource' type='result' query xmlns='jabber:iq:register' instructions All of the requested fields must be filled in. /instructions username/ password/ domain/ server/ port/ /query /iq With Gabber, I see a window that asks for: Domain: Password: Server: Port: Username: With PSI 0.9.3, I see a window that asks for Password: Username: Debug on PSI shows that the packet is received as quoted above, so its a bug in PSI. However, if I register with Gabber, I can still use the gateway with PSI. -- Bruce Campbell Up to version 1.6 now.
Re: [jdev] jabberd2 clusters?
On Tue, 19 Apr 2005, Tijl Houtbeckers wrote: On Tue, 19 Apr 2005 17:00:17 +0200, Bruce Campbell wrote: On Tue, 19 Apr 2005, Mickael Remond wrote: a new release of ejabberd 0.9 has been published. ejabberd is a clustered, scalable, robust and full featured XMPP server. Are there any efforts to have jabberd2 be a clusterisable server? That Ironically you make this reply in the thread about the latetst release of ejabberd. Take a look at that instead.. Erlang just rubs me the wrong way, and I'd like to see more than one free clusterisable jabber server around. Thanks for all the replies; I'll take this to the jabberd list as indicated. --==-- Bruce. ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
[jdev] jabberd2 clusters?
On Tue, 19 Apr 2005, Mickael Remond wrote: a new release of ejabberd 0.9 has been published. ejabberd is a clustered, scalable, robust and full featured XMPP server. Are there any efforts to have jabberd2 be a clusterisable server? That is, something with those nice sexy buzz words of 'redundant' and 'fault-tolerant' across multiple machines without a single point of failure, and no mucking about with multiple domains for the user? --==-- Bruce. ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
