I've implemented a web chat system using Jabber, with the Tigase server and an Ajax-based client communicating over BOSH using JsJac, with Apache mod_proxy forwarding the HTTP traffic to Tigase. This works reasonably well, but I've noticed one major gap in performance versus a desktop Jabber client (like Exodus), particularly when joining a multi-user chat with a long history of messages.
Specifically, from monitoring HTTP traffic, it appears that the server can only send one XMPP message per HTTP request-response cycle. For normal usage this is fine (we're getting roughly 80-100msec round-trip times, which isn't too bad), but when loading MUC history it can be a real drag.
So my question is: does Jabber or BOSH provide any mechanism for bundling or streaming messages that might apply to this use case? Are any clients and servers out there implementing something like this already? Or would I have to modify Tigase and JsJac myself (which is certainly possible, but not ideal)?
Actually, the BOSH server can collect as many responses from the Jabber server and send them as one single response to the client. I am the author of one such BOSH library: http://code.google.com/p/node-xmpp-bosh/.
The response body has nothing to do with the request body in case of BOSH. I mean that the response could and mostly will be a response to an unrelated request (mostly a later request).
I have implemented a BOSH communications solution with Java on the server and GWT on the client (a browser). A C client implementation has also been made. Presently, I am in the process of making the solution available online for tests. Please take a look at the following Google presentation to see if my solution is relevant for your business:
https://docs.google.com/present/edit?id=0AUPL-u98h45WZGQzNWNjOGhfMGd6bWI1NmNk&hl=en&authkey=CPTzrWc
To see the speaker notes, make sure you hit the "View Speaker Notes" button in the bottom-right corner of the page.
Related
I have a Client that tell my server to contact another server and save the data there upon saving if successful I can receive a callback, how can I then tell the Client to refresh the page because this 2nd Server is also sending data to the Client, can I do it using headers?
There is no tranditional ways to push messages (refresh request and so on) to the webpage directly from the server.
Before giving some solutions, I'm sorry to say that your description to your question is quite ambiguous. server, another server, this 2nd Server is also sending data to the Client does not make much sense. You may reorganize your description to show the whole business logic better. Giving necessary code will be better.
So focusing on sending message from server to client within browser environment, there are several ways you could consider:
Ajax
You could use ajax to request the server at client side. You can poll the server at regular intervals, checking the response to determine whether the page should be refreshed.
Pro: widely supported, easy for both client side and server side
Con: polling is not a real-time solution and will make some redundant requests
Websocket
Pro: real-time bidirectional socket-like communication
Con: may be too heavy for the simple task you mentioned
Server push
Part of PWA specification
Pro: allow direct communication from server to client
Con: complexity, insufficient browser support
Nowadays the go-to alternative for real-time browser-based chat rooms seems to be WebSockets. But I remember being in browser chat rooms way before WebSockets saw the light of day. Was it all just based on AJAX polling? Before that I'm assuming it was based on refreshing the actual page.
There were/are some alternatives:
Simple HTTP pooling, e.g. every 5 seconds you make a GET request to get new messages from server. Not very good from traffic point of view.
BOSH protocol https://en.wikipedia.org/wiki/BOSH_(protocol). This is some kind of WebSockets emulation on top of HTTP. I know some projects still use it.
HTTP Long-polling
From what I see, BOSH protocol and HTTP Long-polling are still alive and used in some specific use cases.
What's the reason for not seeing even a handful of "useful" and publicly available websocket based services out there?
RESTful services are plenty like the one below which is weather forecast related.
http://api.openweathermap.org/data/2.5/forecast?q=chicago,us&mode=json
However, why aren't there services like
ws://api.openweathermap.org/...
with some documentation about what messages a websocket client can expect to send and receive bi-directionally over a single connection?
What's the reason for not seeing even a handful of "useful" and publicly available websocket based services out there?
Maybe because websockets were not created for that? They came from the HTML5 initiative and were created to replace Ajax interaction between a browser and a web site for real time web applications. No more polling, long-polling, streaming, flash sockets, or any other HTTP hack to make a server push data to the browser. Webocket is the real thing.
Most web services now follow a request/reply pattern while the websocket is still a maturing technology. Give it time and services will appear, services that actually need the capabilities of websockets and not use them just because "there is a new kid in town".
As a final note, here is something for websockets emerging from Microsoft.
This might sound really naive but I would really find a descriptive answer helpful.
So, my question is this:
I can use Firebug to look at AJAX requests made from any website I visit. So, am I right in saying that I wouldn't be able to examine the same communication between the client and the server if the website choses to use Websockets? In other words, does this make it more secure?
No. Not at all. Just because the browser does not (yet) have a tool to show WebSocket traffic, doesn't make it any more secure. You can always run a packet sniffer to monitor the traffic, for example.
No, because there will be other ways beside the browser-build in tools to read your traffic.
Have a try: Install and run Wireshark and you will be able to see all packets you send and receive via Websockets.
Depends on the application. If you are fully Ajax without reloading the document for data then I would think websockets would provide a better authentication for data requests then a cookie session in regards to connection hijack. Given that you are using SSL of course.
Never rely on secrecy of algorithm cause it only gives you false sense of security. Wiki: Security by obscurity
Remember that browser is a program on my computer and I am the one who have a full control over what is send to you, not my browser.
I guess it's only matter of time (up to few months IMO) when developer tools such as Firebug will provide some fancy tool for browsing data send/received by WebSockets.
WebSockets has both an unencrypted (ws://) and encrypted mode (wss://). This is analogous to HTTP and HTTPS. WebSockets protocol payload is simply UTF-8 encoded. From a network sniffing perspective there is no advantage to using WebSockets (use wss and HTTPS for everything at all sensitive). From the browser perspective there is no benefit to using WebSockets for security. Anything running in the browser can be examined (and modified) by a sufficiently knowledgeable user. The tools for examining HTTP/AJAX requests just happen to be better right now.
Is this chat using "long polling" or "http streaming" ?
http://go-mono.com/moonlight/chat.aspx
It's not anything that simple. It uses http://www.mibbit.com/chat, which is a full IRC client written in Javascript and Java. Blog at http://blog.mibbit.com/.
Edit: Here's your answer.
The first part I got working was the communications between browser and server. That’s done using 2 XMLHttpRequests. The first one is simply to send data from browser to server. It utilizes keep-alive, to minimise new connections.
The second XHR is the ‘receive lazy polling’ one. It connects to the server, and the server holds it open until there are messages available, or a timeout expires. This one is also keep-alive, so the next request goes down the same connection.
What you end up with is 2 connections held open to the server, with packets (json in this case), and some http headers from time to time.
To make sure the server would scale, I wrote a custom webserver in java using nio. It handles all of the connections in a single thread and as I say, scales to tens of thousands of connections.
If the client requests a new connection, it sends a request to the webserver, which then connects out, and starts proxying etc. It also runs an ident server in the case of irc connections so that an irc server can identify individual browsers. I looked at existing frameworks etc to do this sort of thing, but I valued learning how it all works, and thought that my use case may be specific enough to be able to optimise more than general frameworks can.