Can ejabberd chat server be integrated with scalable and fast server technologies like node.js/tornado/socket.io to implement an in-browser chat?
In that case, ejabberd server might run at the backend while front end can use node.js/socket.io etc. to communicate with client browsers. All the chat messages will need to be routed through the ejabberd server. Does all this make sense and is it scalable enough as compared to directly using ejabberd in the traditional way?
Wny not use an existing Candy client (http://candy-chat.github.com/candy/) that runs inside a browser, against backend ejabberd server?
I do not see the benefit in adding a component in your architecture.
ejabberd and XMPP in general are playing well with web technologies and Javascript based client.
There is two major technologies you can use:
XMPP over Websocket is the most modern approach. It is natively supported by ejabberd. It means that you can create a browser-based XMPP client to connect to ejabberd.
XMPP over BOSH. This is an emulation of XMPP connected nature over the request-response nature of the HTTP protocol. It means that you can still do XMPP chat client for browser that do not support Websockets.
Javascript XMPP libraries usually supports both Websockets and BOSH. You can for example have a look at Strophe to implement your Javascript web client.
Related
i want to developp a messenger web app in realtime with nodejs and i wanted to know what's the best choice between websocket and socket.io for the server and the client side.my concerning is performance, like if i use websocket in both server and client side or socket.io what would be more performant. THX
THX.
socket.io was built on top of WebSocket. So there is no chance for it to be any faster than WebSocket. I think the role of socket.io to WebSocket is quite similar to the role of jQuery to Javascript. socket.io has fallback solutions when WebSocket is not available. So basically, it supports more browsers. I personally prefer to use WebSocket over socket.io. It's not because of performance advantage, it's actually about having more controls over the application architecture.
Don't compare Websockets over socket.io, Websocket is a protocol while socket.io is a socket framework (javascript) that uses Websocket as one of it's protocol. Socket.io (client) will use Websocket in communicating whenever it's supported, as a fallback, it will use the old-fashioned polling method when Websocket is not supported by the clients device.
I am wondering if someone has used the socket.io-client library for communicating between servers instead of communicating between browsers to server.
Is this kosher?
Is the behavior of the library pretty much the same when the client library is running on a server vs running in the browser?
Can the socket.io-server library initialize connections with clients, or do socket.io-clients need to initialize connections?
Is this kosher?
Yes, that is exactly what the socket.io-client is designed for. It works great for communicating between two servers.
Is the behavior of the library pretty much the same when the client
library is running on a server vs running in the browser?
Yes, the behavior is identical. The only difference under the covers is that the browser implementation is built on top of the browser's webSocket support whereas the server-side client uses the socket.io webSocket implementation.
Can the socket.io-server library initialize connections with clients,
or do socket.io-clients need to initialize connections?
Only socket.io servers are "listening" for incoming connections. Somebody has to connect TO the socket.io server. You can't connect TO a socket.io client. A client must connect to a server. So, a socket.io client (which can be either in a browser or on a server) must be the one that creates the connection. Once connected, data can be sent either way on that connection.
Considering you are talking about the JavaScript version of the socket.io-client:
Yes, of course it is legitimate to use it server-side. it is just a "client" library, not only a "client-SIDE" library.
The behavior is the same, yes.
Clients need to initialize connections.
There is a server side usage example the Socket.io-client documentation
Other versions of the socket.io-client are also available in different languages (swift, java, CPP), that you can find on their Github page.
I have a web application that requires PUSH notifications. I looked into node.js and socket.io and have an example that's working. The question I have is, Is it possible to use socket.io only in my client side JS without running a node.js server?
Can a third party server just send requests to a proxy server and may be socket.io just listens to a port on the proxy server and sends back events to it?
Thanks,
You need a server side technology to send data back and forth via web sockets. Socket.io is a communication layer. Which means, you need to have a server side method to send data.
However,
You can use various third party services to use web sockets and notifications. They are relatively easy to use, and they have support for many other languages.
Check some of these out:
http://pusher.com/
https://www.firebase.com/
http://www.pubnub.com/
https://www.tambur.io/
https://fanout.io/
You don't need to run Node.js to have a real time push notifications. You can use a third party service that does it for you. Most of them are cheap, sometimes free for low traffic instances.
I have been breaking my head on understanding what exactly is socket.io and its role in the whole persistent communication between client and server in general. Some fundamental questions that keep coming up in my mind are :
Are node.js and socket.io server different ways of doing the same thing ? Like lighthttpd and apache ?
Why should I use socket.io server if I have node.js ?
Can I use socket.io client with another server side programming language like PHP ?
Are there alternatives to using socket.io client ?
Is socket.io client just another javascript library for websocket communication ?
Thanks :)
The Socket.IO server accepts connections from Socket.IO clients. This is not any different than any other server (such as a web server like Apache) accepting a connection from a client (such as a web browser like Internet Explorer).
Node.js is a platform built on top of the V8 JavaScript engine, which comes with a convenient library usually used for web and network applications. Socket.IO is a web-socket-like communication wrapper and RPC which enables servers and clients to communicate over a variety of transports (every thing from long-polling JSON to real Web Sockets). Generally, the Socket.IO server code runs in your JavaScript application running on top of Node.js, and the Socket.IO client runs in your JavaScript on a web browser. (Note that you can run the Socket.IO client in your Node.js application to, which I have used in the past as a quick RPC between multiple Node.js applications.)
There are Socket.IO clients available for many languages, and yes I believe there is one for PHP but I haven't used it personally.
If you want to communicate with a Socket.IO server, you must use a Socket.IO client. It is a protocol all on its own.
Are node.js and socket.io server different ways of doing the same thing ?
SocketIO is actually a I/O engine that permits realtime communication between client and server, unlike classic HTTP requests.
Why should I use socket.io server if I have node.js ?
Since both are differents, we can't compare.
Can I use socket.io client with another server side programming language like PHP ?
No, because socketIO server run in NodeJS environment.
Client first make a HTTP request, then socketIO send a static JS script to client.
This script establish the two-way communication.
But you can use socketIO server with different socketIO client implementation.
Are there alternatives to using socket.io client ?
Any socketIO client implementation can do the job since they connected to server.
But beware of asynchronous way of communication, like in Java or PHP.
Is socket.io client just another javascript library for websocket communication ?
Yes it is, but socketIO aims on reliability and easy to use, and also do best effort : It choose the best transport available for client.
Hope it helps !
Are node.js and socket.io server different ways of doing the same thing ? Like lighthttpd and apache ?
Socket.io is a framework/library for node.js
Why should I use socket.io server if I have node.js ?
It's a framework designed for two-way communication, use it if you want
Can I use socket.io client with another server side programming language like PHP ?
Technically yes. But then you would have to reimplement socket.io server in that other language to match it.
Are there alternatives to using socket.io client ?
Lots of, google for websocket/real time communication in [here put your language]
Is socket.io client just another javascript library for websocket communication ?
Socket.io client is a JavaScript library compatibile with socket.io server (which is JavaScript library as well, only on the server side, i.e. Node.js)
I'm using the node WebSocket Server ( http://static.brandedcode.com/nws-docs/ ) in nodejs for websockets and one java client using this websocket client https://github.com/TooTallNate/Java-WebSocket. I couldn't use socket.io as a server because i couldn't find any java clients for it. Now i've searched for a javascript client for Websocket server, and can't find any. Anyone know of any generic web socket clients in javascript? The socket.io client is not connecting to this server. Thanks for any help.
javascript client for Websocket server
It's called window.WebSocket.
If you want fallbacks and browser support (The thing socket.io is good at!)
Try
web-socket-js
Atmosphere (A completely different framework)
I couldn't use socket.io as a server because i couldn't find any java clients for it
Read the socket.io source, write a Java WebSocket client for it. It should only be a thin abstraction ontop of your Java-Websocket.
Personal advice is to make Java support socket.io. Although I don't see why your doing Java - node.js communication over websockets instead of tcp or udp. The latter two are probably better