Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] XMPP

Hi Ali,

Ali Naddaf wrote:
Scott,

As usual, thank you very much for your detailed response. I will open a couple of enhancement requests to make sure things don't fall through the crack and are documented somewhere; and if I can provide any help with either defining the requirements, implementing or testing, I am all for that.

Just to give you an idea why I am interested in the XMPP provider, let me explain in a few words: in my usecases, the parties that want to reach each other (i.e. invoke each others' services) are almost always NAT'ed behind some routers or some other devices, so they are not publicly exposed/accessible. Having a publicly available server such as Google's Jabber server is ideal since all those NAT'ed services can easily and reliably get in touch with each other without any trouble, even though they are NAT'ed. Among other providers that ECF has in its bag of tricks, are there any other candidate that can provide the same functionality for me to use besides the XMPP provider?

Yes...there is the JMS/ActiveMQ provider...i.e. if there is an ActiveMQ broker that clients can connect to...that is not on the NAT...then the clients can expose remote services to each other as long as they are in a common pub/sub group that is exposed by the ActiveMQ broker (i.e. communicate with each other via the broker/server).

And by "the same functionality", I mean a relatively easy way of discovering each other without me installing any publicly available server, etc.?

I would venture to say that a publicly available server (xmpp or jms broker) would most likely be necessary...so of the existing providers there is/are xmpp, ECF generic (where you can make a publicly server available, JMS and javagroups. Javagroups depends upon multicast ip...and this is frequently not available on the wan (i.e. across lans/through routers). Of course if you wish you could implement your own provider based upon the protocol of your choice...as long as you have some server or broker to use to provide client-to-client connectivity.

If so, I am open to looking into them as well. Hopefully that helps you understand my usecase and my particular interest in the XMPP.

XMPP seems like a good choice, I believe...primarily because there is a publicly available server/servers that you can use for free...and not have to implement/create/deploy/manage yourself. The good news here (creating your own provider), is that you can easily reuse a lot of what's already been done for other providers.

Thanks,

Scott



Back to the top