Hi, On Tue, Aug 16, 2011 at 4:15 PM, Waqas Hussain <[email protected]> wrote: > 2011/8/16 Jehan Pagès <[email protected]>: >> Hi, >> >> so I have just implemented something with XEP-0114 (client side) and I >> have a few questions. >> >> (1) In my case, the component was locale. And I imagine that's quite >> the most common case. But that's definitely not an obligation >> (especially as we could imagine "component service providers"). Hence >> TLS encryption should be possible. >> >> Maybe it is, but XEP-0114, definitely tells nothing about it. It looks >> like the way-to-do is connecting and directly handshake in plain text. >> Maybe a <features/> logics would be nice. It would allow TLS, compression, >> etc. >> This could be added in the same time we pass to an SASL authentication >> for component. > > Correct. We have been aware of these issues for some time. That's why > XEP-0225: Component Connections exists. > > XEP-0225 is the way forward. However, there aren't many > implementations. I suspect the reason is that XEP-0114 is good enough > for most. Most component deployments are on the same machine as the > XMPP server, and using TLS or compression in that case is rather > pointless.
I guess it is in most cases. I was more thinking in a generic point of view. That's easy to imagine infrastructure with a remote component. Anyway I'll have a look to XEP-0225 then. > We plan to add support for this to Prosody soon. It can enable all > sorts of interesting features not currently available to components. > >> (2) Is there not any default port (xmpp-component) for components, >> same as we have default ports for xmpp-client and xmpp-server? >> Or do we consider it the same as the "secret", which is that anyway >> every component is expected to use a different port, that is known >> only by configuration? >> Note that this point does not annoy me. After all, components are >> specific configured items (and usually limited) so we can consider the >> port as a "configuration-only" information. Nevertheless a text about >> this point may be worth added in the XEP to better explain the logics. >> Also I think a server implementation should allow for multiple >> components on a single port (I did not test if they already do this. I >> just say we should add the text). If your server has 20 components, >> you might prefer not to have to each time you add a component, open a >> new port, but simply use the same as for your other components. > > Some older servers in fact require that each component be on a > separate port. XEP-0225 solves this too. We just need to get everyone > to start using it :) Ok. >> (3) The current logics seems to be that the component connects as >> component.shakespeare.lit, keeps a long-live connection and from there >> sends stanzas as [localpart@]component.shakespeare.lit[/resource] and >> process any message sent to such an address. >> That makes sense in this very common connection logics. >> >> Now I have a use case where I would like to be able my component to >> connect as different "entities" on this component. Basically I cannot >> make a long-live connection. So I just want to be able to connect >> several times. >> For instance the component could connect as: >> <stream:stream >> xmlns='jabber:component:accept' >> xmlns:stream='http://etherx.jabber.org/streams' >> to='plays.shakespeare.lit/someresource'> >> >> Or it could be also with a localpart (basically any JID that the >> component plays.shakespeare.lit has control on). >> For this kind of use case, we would want routing rules. >> Basically if I connect with component domain part only, I would want >> to receive any stanza. But if there is a stanza sent to a given >> resource, and if the component is connected with this resource >> specifically, it would grab the priority to receive this stanza. On >> the other hand, the component connected with a resource must not >> receive any stanza if another precise resource is specified. >> >> And so on. Basically I propose to take into account this new kind of >> component connection logics with routing rules (that we could now >> discuss, or I could just propose the list of rules which I have in >> mind). >> That does not prevent the current usual logics: a single connection, >> long-live, as the main component domain part. But that allows new >> logics with multiple connections and appropriate routing. >> What do you think of this? > > What's the use-case? And I'd like to see your proposed rules, > particularly how it works when a component goes down. > Ok I'll put down these rules and send them. The use case is a wordpress plugin I wrote which implements XEP-0070. Basically the first implementation was with a bot ([email protected]). Simply if someone requests an access, I connect the bot with a random resource, sends the request, stays connected a limited time and if I get the response in this span of time, I grant access to the user. Typically I can't have a single resource always connected in this architecture (of course another solution would be to have a daemon with this bot and the website talks with this daemon. But this kind of solution is more complex, hence would not be suitable as a on-click easy-installable Wordpress plugin). This solution is quite efficient and works very well with a bot thanks to the routing rules on full JIDs. Now I implemented a component alternative (component.shakespeare.lit). But reading the XEP and after a few basic examples, I feel I would have concurrency issues with several people connecting in the same time because I cannot ensure which "connected component resource" the user's response will reach. I may therefore work around with some other solution by sharing data between the various concurrent executions, but that's counter-efficient and make things over complex (while I would prefer to put this complexity on the server). Right now, only the bot version is really reliable. So I would like to propose routing rules to give a chance to a component with such an architecture. Obviously these routing rules won't change anything for typical component with a single process connected. But that allows alternatives. Jehan > If it's load-balancing, the reason we don't have a standard is because > there are multiple possible load balancing strategies, none of which > is perfect. > > Prosody allows components which are "node@host" or "host/resource". I > haven't verified if this works for external components, but we've used > it to do a number of interesting things with internal components > (e.g., MUC loaded on "[email protected]", with "example.com" being a > normal host with user accounts). I see. Interesting. I should test someday. Anyway I have been thinking for quite some time to test Prosody. Thanks for the answer. Jehan >> Jehan >> > > -- > Waqas Hussain >
