Why use http(s)+comet and not simply socket programming?

Question

Why use http(s)+comet and not simply socket programming+maybe use the same port 80 or 443 if firewall/blockage is an issue?

Wait, perhaps because browsers don't have javascript sockets API?

If I am building an independent application and not a web-app, does comet have any advantage over socket programming?

Answer 1

You're right, the security model of web browsers doesn't allow for traditional socket programming. Although, the newer HTML5 standard describes something called WebSocket implementing similar functionality.

There's of course nothing stopping you from using whatever port to do whatever if you're building an independent program. Some sysadmins might find it somewhat bad form to claim port 80 or 443 for custom protocols, and in many it setups these ports are already used for their traditional roles. But that's specific to the networks in question.

Edit: Since Comet/HTTP(S) connections were created to work around limitations in the browser they have no special advantage over socket programming. Choosing witch method to use is mainly a question of performance: the more important the performance, the bigger the reason to use sockets and vice-versa. Which method has the best support of your framework should also weight in on the decision. Subjectively, I would lean towards using socket programming if no browser was involved.