Tuesday November 28, 2006
Tuesday November 28, 2006 One of the things which we introduced with the previous interim release
was the concept of server pool.The admin can have a combination of
disparate set of boxes - solaris sparc/x86, linux and logically combine
them to create a single XMPP deployment.Ofcourse, one deployment could
support multiple hosted domains - so typically it is a single
deployment : not really a single domain which is hosted on a pool.
For the purpose of minimising internode communication, we have also introduced to concept of an xmpp aware load balancer called redirect server.The actual redirection mechanism is an spi and can be customized, but there are a bunch of out of the box methods - including ones which allow for roster based logical grouping of contacts to nodes.The server pool will redistribute any new load across itself in the face of failures ... So, introducing redundency into the pool not only helps in performance of a single node under normal operation, but allows the pool to operate smoothly when you are faced with network, power, etc outages.
Taken together this results in some interesting usecases.
There is minimal network overhead and yet high degree of failover and scalability can be achieved - we have not really tested to reach the limits of how 'large' a server pool can be .... This essentially means that a service provider can not only support a large number of hosted domains, but also provide high availability for all of them with a single deployment.
As far as the end user is concerned, there is no difference whether he is talking to a server pool or to a single server: the behaviour is uniform and spec compliant.
If you consider the distributed nature of features like pubsub, muc, etc in the server pool - it essentially means that you do not have the concept of failure: unless every node in the pool goes down that is
So essentially, you can use the server as a near-realtime messaging middleware with very high availability and scalability.
And yes, the next release we have does include expirimental support for caps and pep at the server and in client api ... might not be the latest version of the spec though. But developers wishing to hack at it are welcome : this impl is not very rigourously tested - so I am not going to popularise it, but we have used it for avataar and seen it working beautifully
!
The api which is hosted at collab project of netbeans has the client side support for this (:pserver:anoncvs-AT-cvs.netbeans-DOT-org:/cvs , collab/service/src/org/netbeans)
Btw, did I mention that we have always supported privacy lists ?
For the purpose of minimising internode communication, we have also introduced to concept of an xmpp aware load balancer called redirect server.The actual redirection mechanism is an spi and can be customized, but there are a bunch of out of the box methods - including ones which allow for roster based logical grouping of contacts to nodes.The server pool will redistribute any new load across itself in the face of failures ... So, introducing redundency into the pool not only helps in performance of a single node under normal operation, but allows the pool to operate smoothly when you are faced with network, power, etc outages.
Taken together this results in some interesting usecases.
There is minimal network overhead and yet high degree of failover and scalability can be achieved - we have not really tested to reach the limits of how 'large' a server pool can be .... This essentially means that a service provider can not only support a large number of hosted domains, but also provide high availability for all of them with a single deployment.
As far as the end user is concerned, there is no difference whether he is talking to a server pool or to a single server: the behaviour is uniform and spec compliant.
If you consider the distributed nature of features like pubsub, muc, etc in the server pool - it essentially means that you do not have the concept of failure: unless every node in the pool goes down that is
So essentially, you can use the server as a near-realtime messaging middleware with very high availability and scalability.
And yes, the next release we have does include expirimental support for caps and pep at the server and in client api ... might not be the latest version of the spec though. But developers wishing to hack at it are welcome : this impl is not very rigourously tested - so I am not going to popularise it
, but we have used it for avataar and seen it working beautifully
!The api which is hosted at collab project of netbeans has the client side support for this (:pserver:anoncvs-AT-cvs.netbeans-DOT-org:/cvs , collab/service/src/org/netbeans)
Btw, did I mention that we have always supported privacy lists ?
Saturday November 18, 2006 File transfer to a Multi user chat is not defined in the current set of xmpp extensions.
Though this does not really describe what our server/client does today, this post discusses a simple means to achieve this required functionality.
[Read More]
Wednesday November 15, 2006 Some random thoughts on presence probes in rfc 3921 and the xmpp bis specs ... just random rambling, I could be grossly wrong !
[Read More]
Monday November 13, 2006 A small summary of primary features to expect in security and authentication in the upcoming release of Sun's IM server
[Read More]
Friday November 10, 2006 Elaborated the idea posted in the previous post along with some clarifications and corrections.
[Read More]
Wednesday November 08, 2006 Discusses a potential proposal we are considering to implement which will minimise the interserver traffic tremendously without compromising on security, responsibility and accountability.
[Read More]