Tuesday Sep 12, 2006

No progress for a loooong time

Yep , been ages since I did anything at xmpp-im-client : and all blame to be laid on me.
One thing let to another and I was neck deep in fixing the server up quite a bit !
The next release when it does come out is going to be quite interesting :-)
Some very interesting usecases are going to be possible ... patience for a couple of months more !

So , I will need to tie up loose ends for a couple of more weeks : and then hopefully I will be able to get enough of my life back to actually start working on the project.

Friday Jun 23, 2006

Explaining the auth code ...

Now to explain what is checked in ... the main purpose of the whole project :-)

Essentially a simple framework for authentication has been checked in. Let us take a look at the Classes involved.
There is a AuthenticationManager in net.java.dev.xmpp.client.core , which handles the actual session creation and management.

In the collab api , you create a collab session using a CollaborationSessionFactory - which delegates the actual session creation to an instance of CollaborationSessionProvider.
The default CollaborationSessionProvider is org.netbeans.lib.collab.xmpp.XMPPSessionProvider - this allows us to create a direct socket based session to a XMPP server.
Other CollaborationSessionProvider that can be used are :
  1. org.netbeans.lib.collab.xmpp.XMPPSecureSessionProvider - This provider allows you to use legacy SSL to the server. This is a deprecated jabber protocol where the server always listens on SSL mode : like what you have in http/https case.
  2. org.netbeans.lib.collab.xmpp.XMPPComponentSessionProvider - This allows you to create a 'trusted' component session : please refer to JEP 0114 for technical info.
  3. org.netbeans.lib.collab.xmpp.ProxySessionProvider - This provider allows you to create a XMPP session tunneling through HTTPS or SOCKS proxy. The actual proxy to talk to is picked up from the service URL.
  4. org.netbeans.lib.collab.xmpp.XMPPSecureComponentSessionProvider - allows creation of component session when server is in legacy SSL mode.
  5. org.netbeans.lib.collab.xmpp.httpbind.HTTPBindSessionProvider - allows creation of a HTTP based XMPP session as per JEP 0124. The connection related info is picked up from the service URL.

To use a non-default provider , you will just need to specify the classname as the parameter to CollaborationSessionFactory constructor (in our case , constructor of AuthenticationManager) ! Rest of the details are taken care of by the collab api - and it exposes a uniform behaviour irrespective of the underlying transport : even when the underlying transport is not a dedicated socket stream like in httpbind case !
Ok , almost ... there are a couple of little details a user still has to take care of .... let us finish those of too.

If in the process of session establishment , an untrusted certificate is provided as part of TLS , the decision whether to accept the certificate or not depends on what the provided CollaborationSessionListener says.
That is , if the listener is an instance of org.netbeans.lib.collab.SecureSessionListener , then the corresponding "onX509Certificate" method is invoked ... else the certificate is treated as untrusted and session terminated.

If the service URL points to the form "host:port" , the collab api uses that directly as the destination XMPP server/port.
In case it is of the form "domain" , it tries two things one after the other.
  1. It tries to do a dns query for the specified "domain" to try to find out if there is a xmpp service registered for it. If yes , it uses that as the destination server. This way , the actual xmpp server hosting a domain could be decoupled from the domain itself. Refer here for more details.
  2. If (1) is not the case , the api treats "domain" as XMPP host with default port of "5222".
Well , not always - service URL is overloaded to mean something specific in case of two providers ... as explained below.

ProxySessionProvider and HTTPBindSessionProvider use the service URL as a way to obtain required parameters.
In all the other providers , the service URL is just the destination "host : port" (or domain in case you want to do a dynamic lookup of the XMPP host servicing that domain).
In these two providers , the semantics are different , let us see how :

  • ProxySessionProvider
As of now , the service URL is expected to be in the form :
<protocol>://<proxy host>:<proxy port>?(name=value)(&name=value)\*

The protocol can be one of "socks" or "http"/"https" : socks will tunnel through a socks proxy , while http or https will tunnel using http CONNECT.
The query names currently handled are :
  1. "keepalive" : After authentication succeeds , the client will send whitespace pings to the server after each keepalive interval : this is so that intermediate proxies do not terminate the connection assuming it is inactive.
  2. "authname" , "password" : The authentication credentials to talk to the proxy.
  3. "service" : The 'actual service url' !
  4. "usessl" : Whether to use legacy SSL to talk to the XMPP server after tunneling through the proxy.
So an example service URL would be of the form :

  • HTTPBindSessionProvider
The service URL in the case of this provider is the actual URL used to get in touch with the httpbind gateway ... except for the fact that the query parameters are removed.
The actual query parameters are defined in org.netbeans.lib.collab.xmpp.httpbind.HTTPBindConstants ... and allows for a wide range of customisations. The only mandatory query parameter is the "to" parameter.
This specifies the domain the user wants to log into : and should be serviced by the specified httpbind connection manager.

Another important point related to httpbind is related to proxy support.
The default two ConnectionProvider's for httpbind do not support proxies directly.
But , they use URLConnection to get to the httpbind gateway , so you can specify the appropriate proxy using the corresponding java properties and expect them to be used.
The main reason why they do not support it is 'cos the 1.4 java.net.\* code does not provide a way to explictly specify a proxy... as and when the api moves completely to 1.5 , this implementation will get revised.
Ofcourse , you can always write and provide a custom ConnectionProvider in the service url which picks up the proxies and uses it !
Please note that "proxytype" and "proxyhostport" is expected to be provided even if you explictly set the java proxy vairables ... this is so that is the collab api's move to 1.5 and start using the java.net.Proxy class , the client code should not need to be modified.

So a sample HTTPBindSessionProvider service URL would be : https://my_gateway_host:port/codebase/httpbind?max_buffered_bytes=1000000&max_buffered_packets=1000&to=sun.com&proxytype=http&proxyhostport=myproxyhost:port

Other than specific customisation's , there is nothing much else that needs to be taken care of !

[Technorati Tag: XMPP]
[Technorati Tag: Sun IM api]
[Technorati Tag: xmpp-im-client]

Wednesday Jun 21, 2006

Checkins finally !

First off , I took much more time than I anticipated before I could finally make some checkin's to xmpp-im-client.
Without giving excuses , I will just mention work as the reason :-)

Ok , now that we have cleared that , what has been checked in ?
  1. Very basic skeleton of the project - how it would be structured , how it will use external api , etc.
  2. The first few pieces of code ! (More on this below).

The basic skeleton of the package structure , build structure , etc has been checked in - if you are part of the project (if you are not , what are you waiting for !) , feel free to comment about it in case you have any reservations or suggestions.

A few classes have been checked in :
  1. A session manager which takes care of creating session's and handles reconnections as needed. This is envisioned to be common across UI modules.
  2. A basic simple CLI based UI has been checked in - as of now , it does nothing other than create a XMPP session using the collab api (using the wrapper described in prev bullet).

So session creation is done .... almost.
What else can be done ?
  1. Change the sessionprovider passed to AuthenticationManager to try out different providers : legacy ssl , httpbind , proxy support , etc !
  2. If required , implement org.netbeans.lib.collab.AuthenticationListener also in CliSessionListener - this will allow you to select and control SASL based authentication.
  3. For more advanced SASL support - like custom client SASL modules , along with (2) above use <AuthenticationManager>.getFactory().getCollaborationSessionProvider().registerProvider( <SASLClientProviderFactory> ) !

Though the code checked in looks deceptively simple , it handles almost everything required for session creation - including reconnection when connection gets dropped.
The next functionality that we target will be just reusimg the CollaborationSession that we created using the above to build on to add more complex functionality !

Check out the discussion forum where I have added some blurb on how to test this.

So here to happy IM'ing !!

[Technorati Tag: XMPP]
[Technorati Tag: Sun IM api]
[Technorati Tag: xmpp-im-client]

Wednesday May 17, 2006

Discussions at xmpp-im-client

Initial idea was that I will just forge ahead with design/coding and add stuff/refactor things as they develop.
When I saw that a small number of other developers have joined in the effort , decided to slow things a bit and atleast discuss the design before going ahead. The smattering of snippets on my workspace will remain there until we come up with some basic agreement.
This is the right time to join in case you want to influence the project from the start !
The unexpected delays have been , as I explained before , due to some deadlines at work - which have been cleared : full speed ahead !

I have also created a new Category "XMPP_IM_Client" in my blog under which I will post discussions and posts on this topic.

[Technorati Tag: XMPP]
[Technorati Tag: Sun IM api]
[Technorati Tag: xmpp-im-client]



« July 2016

No bookmarks in folder