We Keep Coding

MQTT as a centralized communication protocol

I want to implement a service for a great number of devices. This service should be able to send/receive (small - max 1kB) messages between server and client, but also p2p between device and device.
For now I am thinking about achieving this with MQTT, as it seems to be a lightweight low traffic generating protocol. As stated in this question XMPP might also be an alternative, but I'm not sure if this is giving me the performance I need.
Summarized I have the following expectations for the protocol:
Small Overhead
Small Payload
High number of clients (starting with 100.000)
Handles unstable network connection
Scalability for example by using multiple broker instances
P2P Connections between clients (could be solved with an involved server)
If possible open source implementations in Java, JavaScript and C++
Is MQTT the right approach for me or should I better look at some alternatives? Please keep also in mind that I would need to create a highly scalable service.

I think all your expectations except for 6. can be fulfilled with MQTT if you use it the right way. You should have a look at http://www.eclipse.org/paho/ and http://mosquitto.org/ for OpenSource implementations.
As MQTT has a publish-subscribe architecture where every message is send to and distributed by the message broker (server), P2P might be a problem. You could use a dedicated topic for every connection between two clients, but the messages would still have to pass through a message broker.
As a workaround, you could negotiate a P2P connection between clients over MQTT and then use the negotiated channel with another protocol.

As leikes said, with MQTT you have all the features you need and the point 6 is achieved using a broker.
The big lack for MQTT is that it doesn't support request/reply pattern natively (like HTTP or AMQP) but a full support for publish/subscribe pattern.
Of course, if you need request/reply you need to do it into a layer above the protocol itself defining right topics and payload to create a matching/correlation logic between request and response.
Paolo.

Is there a way to send a TCP request to the client through the browser?

I am working on a web application. I want to know certain parameters of the client's machine. I have been able to find out most of the parameters but I am struck in the following parameters.
1) TCP Timestamp
2) TCP/IP FingerPrint
So, my question is, Is there a way to send TCP request to the client through my web application(assuming I know the client's IP address). Or is there any way around to find out these parameters on the client's machine. Any hint on how to get started will be appreciated.

So, my question is, Is there a way to send TCP request to the client through my web application(assuming I know the client's IP address). Or is there any way around to find out these parameters on the client's machine. Any hint on how to get started will be appreciated.
If you can use sockets (not websockets) from your web application than you could try to establish a TCP connection to the client. But this will probably not work in most cases, because:
The client will not listen for TCP connections from outside, so you would get at most a RST packet.
Clients are mostly behind some NAT device today, like a router at home or inside a mobile network. Therefore the source IP you see from the client connection to your server is in most cases not the IP of the client itself, but of the NAT router. Since the client has no public IP address it can not be reached directly.
1) TCP Timestamp
2) TCP/IP FingerPrint
These are usually not parameter you find out by doing a simple TCP request, but you need to work with raw sockets. Also, part of these information can be derived from the established connection, but you must be able to track the connection on the raw level (like with tcpdump).

Is a web socket connection in javascript an inbound connection?

I'm trying to make a web socket connection on my webserver. The connection is run from a client in javascript and connects to a php script on the webserver. The javascript is also placed on the webserver, but runned from a clients webbrowser.
The problem is that hostgator doesn't allow inbound socket connections unless you buy a dedicated server, but I'm not aware if this counts as an inbound socket connection.
So does anyone know if this counts as an inbound socket connection or any other web hosting sites that would allow inbound connections?
Thank you in advance :)

A websocket connection starts life as an incoming HTTP connection (usually on the same port as is being used for web requests) with some custom headers on it which is something all web servers have to be configured to accept (or they wouldn't be any use as a web server). After a brief exchange with the client, the client requests an upgrade and a switch to the websocket protocol (the initial connection was the HTTP protocol). That connection which started life as an HTTP connection then becomes a webSocket connection (if the web server agrees to the protocol switch).
So, yes it is an incoming connection to the web server, but it's an incoming HTTP connection which your web server has to already accept. webSockets were designed this way on purpose to make them highly compatible with existing HTTP networking infrastructure, firewalls, etc... so they could be used by only upgrading the HTTP server software (to support the webSocket protocol) and not changing any of the networking infrastructure.
FYI, there are other hosting issues with using webSockets. A webSocket is a continuous, long lasting socket connection. In order to use it, you typically need a continuous, long lasting server process. Many of the lower cost, shared hosting environments do not support that. They tend to accept an incoming HTTP request, dispatch it to whatever script it is supposed to run (e.g. a PHP script), let it run on that request and then the script exits and your server process does not continue to run. This works well for low cost, shared hosting because no server resources are consumed by your app when it is not actively in the middle of serving a page. But, that model won't work for webSockets where you must have a continuous server process for the webSocket to be connected to.
I don't know specifically about hostgator, but this is another issue to look into. On my shared hosting on Dreamhost, I cannot have a long running server process. On Dreamhost this requires a VPS hosting plan and from what I've read this is common for other shared hosting environments too.

How to send a UDP Packet with Web RTC - Javascript?

How do you send a UDP Packet using Web RTC?

You can't send a UDP packet directly with WebRTC. That would violate the basic security constraints required by the browser.
You can send SRTP to an ICE-enabled host. That is probably not what you are looking for.
If a browser permitted sending arbitrary UDP packets, then malicious applications could send packets to any host.
This might not sound so bad, after all, hosts on the Internet need to be able to deal with that right? The problem is that some browsers are in protected environments where access to the network is restricted. Within those networks, some hosts are far less protected than a host on the public Internet might be. This would be OK, since access to the network is controlled.
If it were possible for a browser to send arbitrary packets, a user on a browser in that environment could be convinced to send specifically crafted packets to one of these poorly protected hosts. Likely, that would result in the network operator banning the browser, which is something browser-makers want very much to avoid.
WebRTC only sends certain types of UDP packet under specific conditions. If the host that you are interested in talking to understands ICE and is able to consume RTP with SRTP or SCTP over DTLS (unlikely methinks). Then perhaps you could force the browser to send something.

You should check sipml5, http://code.google.com/p/sipml5/
get the code and look into the folder:
sipml5/src/tinySIP/src/transports

#Martin Thomson has explained the problem very well. By taking
motivation from his post, this post might provide guidance to some
geeks and newbies.
It is being said that WebRtc is Real-time, Bi-directional, Secure communication between two or more peers. I will more focus on the word: Secure.
Security policies of enterprise networks typically require filtering of incoming unsolicited traffic, blocking certain protocols, and doing application-level filtering and scanning for spam, malware, and intellectual property.
Now two new questions come to mind;
Why is TCP traversal not problematic?
Why is UDP traversal problematic?
Why is TCP traversal not problematic?
TCP clearly indicates two things;
The beginning of a flow (SYN) and,
The end of a flow (FIN or RST).
This is used by firewalls to open and close pinholes. Exceptionally, a TCP connection that has received no traffic for a long time also has its pinhole closed (to accommodate network topology changes or failure of both TCP peers). Firewalls also perform protocol validation to clean up problems with
Out-of-window TCP segments and,
Overlapping TCP segments
This allows the firewall to protect the network and protect hosts from
several attack vectors (replay attacks, host IP address probing, DDOS
attack, etc.).
Why is UDP traversal problematic?
For UDP flows, the first outgoing packet on a 5-tuple will be used by the firewall as a start-of-session indicator. But UDP does not have an end-of-session indicator, so the firewall has only two ways to close a pinhole:
Timing out the pinhole after the interior host does not send traffic
for several seconds or
The interior host generates a fatal ICMP error.
Because there is no reliable way to determine that a session is being stopped, the firewall has a much harder job. It could implement an Application-level Gateway (ALG) and be aware of whatever semantics are imposed by the higher-level code on top of UDP.
It could also rely on a set of well-known application servers to inform it of sessions as they start and end, but that suffers from many challenges as application servers are hosted independently of the network on which they are used.
Using an ALG, a firewall can determine when the call is terminated and
close any dynamic mappings created for the media session. But the
problem is session signaling between the WebRTC application running in
the browser and the Web server that could be using TLS, in which case
the ALG no longer has access to the signaling.
Conclusion:
So, at the Application-Level Gateway, Webrtc utilizes a combination of SDP and ICE. WebRtc basically wraps UDP in such a way that
For Audio, Video Channels, WebRtc uses combinations of RTP, RTCP, SRTP over DTLS.
For Data Channels, webrtc uses the Stream Control Transmission Protocol (SCTP), defined in RFC 2960.
SCTP is a transport layer protocol that was intended as an alternative
to TCP or UDP. For WebRtc, we use it as an application layer
protocol that runs over our DTLS connection.
These protocols also come with some new protocols such as STUN, TURN. For the basic implementations of WebRtc Please follow;
WebRtc Experiments by Mauz Khan
WebRtc Experiments by Muhammad Usman Bashir
I hope this explanation might help some of the geeks. Thanks

How can i do a client to client (browsers) socket connection?

I have been thinking about building a client to client program. But the way I want is to use the broswer to do it, helped by a server that can make that connection.
The troubles comes when I need to have an unnconected socket (or pasive) in a client, waiting for a connection.
I have been thinking about Html5 WebSockets, but it doesn't give to the client the posibility of having a pasive socket without connecting it with a TCP protocol.
I'm learning this and trying to find the way to do this. All ideas are wellcome :D.

You can have a passive socket in Java applets, Flash and other browser plugins, but in general that can be problematic for public web applications.
First of all it will be difficult to get through firewalls, etc, and you'll need to depend and write code for a browser plugin that implements a socket API, and bridge it to JavaScript. If you are interested in some solutions, you may want to check out the following Stack Overflow post:
How can I communicate over TCP sockets from JavaScript?
The traditional approach for peer-to-peer communications between browsers is to have your server acting as a gateway for all the connections. Browsers initiate the connection (either with WebSockets or with XMLHttpRequest) and keep an active connection to the server at all times, re-establishing it if it drops. Since the server application will always find an open TCP connection to all the connected browsers, it can easily route messages to/from all clients.

As Daniel says, you are going to have a very hard time trying to do true peer-to-peer (a la Skype etc) in the browser, and it is certainly not possible without the use of plugins. And even Skype etc rely on falling back to a server acting as a gateway when a direct connection cannot be established (due to firewalls etc).
So you really need to have a gateway server regardless, and that there are a number of options. Try searching here for 'comet'. Some options that I have played with include Orbited (http://orbited.org/) and Hookbox (http://hookbox.org/) but there are many others.