Sockets in JavaScript (HTML5)

Quote:

Original post by ozak WebSocket API needs a special protocol implemented serverside

WebSockets are effectively the same as TCP. Server is provided a stream they receive data from and to which they can write.

Quote:

I don't really have any experience with Ajax, so I don't know if it can be used for socket programmeing (initial google results says no)

Ajax is client-side mechanism to make a HTTP request to server.

Quote:

Anyone got any experience/ideas?

What are you trying to do?

Thanks for your response

After some more research, it turns out that you just need to do the proper handshake before using WebSockets for text based UTF-8 socket transfer.
However, I can't seem to get this handshake working properly as the client keeps closing my connection.

Also Ajax seems to have issues with keepalive and is indeed HTTP request based which is not quite what I want.

I just want a socket connection where I can send/recieve strings from my server while keeping the connection open.
I guess I just have to look into implementing the WebSocket handshake properly or go the flash route

/Ozak

Yeah you'll probably want to use real sockets. However, I will point out that if AJAX requests are made within a 5 seconds interval (default for most server it seems) then a persistent connection is used. So as long as you send data back and forth at anything faster than 1 packet every 5 seconds then you're normally fine.

For the comet server I programmed I realized something else. Firefox, and I assume other browsers have this as well, but you can only have 4 pending XMLHttpRequest's open at a time. It works like a queue. As one is processed by the server the browser will send another. This isn't much of a problem.

Doing it the AJAX way works and I believe is feasible for a real-time game. However, the part I didn't like is that with the TCP and HTTP overhead you're looking at around 100 bytes overhead for every "packet" you send.

Yep. I saw some tricky JS examples keeping the connection alive, but as you said too much data being transferred.

Did you by any chance implement WebSockets in your server? ;)

Thanks

/Ozak

Quote:

Original post by Sirisian For the comet server I programmed I realized something else. Firefox, and I assume other browsers have this as well, but you can only have 4 pending XMLHttpRequest's open at a time. It works like a queue.

HTTP specification, 8.1.4:

Quote:

A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion.

Since this is recommendation, most browsers use 4 these days. It's possible to change this value in browser settings, but it will not necessarily help, as it may cause problems with various routers. Other solution is to spread calls across multiple servers, but that is difficult with AJAX due to same-domain restrictions.

Quote:

After some more research, it turns out that you just need to do the proper handshake before using WebSockets for text based UTF-8 socket transfer. However, I can't seem to get this handshake working properly as the client keeps closing my connection.

Are you using HTML5 client which supports WebSockets? It's still experimental, so it will most likely be partially implemented in various dev builds, given the non-final status of HTML5 spec, existing release versions are likely to have only provisional support.

Yup. Chrome supports WebSockets. I do however agree with this guy here: http://www.reddit.com/r/programming/comments/7a3rc/html_5_websocket_is_neither_web_nor_socket/

It's broken that we don't have proper socket support and have to wrap strings in special character codes etc. etc.

There's some interesting links in the comments section, which I will check later when I get off work :)

/Ozak

Quote:

Original post by ozak Yup. Chrome supports WebSockets.

Version 5 supports some interpretation of draft specification, with not much emphasis on strict compliance. Version 6 dev builds support various degrees of recent changes to the draft.

Quote:

I do however agree with this guy here: http://www.reddit.com/r/programming/comments/7a3rc/html_5_websocket_is_neither_web_nor_socket/

That article is almost 2 years old - and even today there is no final standard.

Quote:

It's broken that we don't have proper socket support and have to wrap strings in special character codes etc. etc.

There is nothing wrong with that. Web sockets are supplement to HTTP, which is primarily about transferring text data. Those restrictions and non-printable separator are not a problem as such.

Even so, the problem of escaping or alternate encoding has been solved way back in the Usenet era and beyond, in simplest form using base64 encoding. Considering all other inefficiencies, this part of spec is fine.

Quote:

Original post by ozak Did you by any chance implement WebSockets in your server? ;)

Nope. As mentioned they're not well supported yet. Also I've done a lot of Flash network stuff so I'd probably just use an external interface and use that for the networking. I'm mostly just messing around at the moment to see how things work.

One thing that I didn't mention is that with XMLHttpRequest only FF supports sendAsBinary which can be annoying. I use it send small binary packets which helps to negate the overhead caused by http. Also I said 100 bytes, but honestly it's not that high. I have the number written down since I tested it. I'll check when I get home and probably edit my posts.

//edit: Breakdown of the smallest I was able to get the http overhead. I'm sure not all of that stuff is necessary.

[Edited by - Sirisian on June 7, 2010 3:40:23 PM]

Quote:

Original post by Antheus Quote: It's broken that we don't have proper socket support and have to wrap strings in special character codes etc. etc. There is nothing wrong with that. Web sockets are supplement to HTTP, which is primarily about transferring text data. Those restrictions and non-printable separator are not a problem as such. Even so, the problem of escaping or alternate encoding has been solved way back in the Usenet era and beyond, in simplest form using base64 encoding. Considering all other inefficiencies, this part of spec is fine.

I have no problem with sending strings. My whole server is based around that :)
The problem is that I have to make some wierd connection header and wrap my packets. But you're right. There is no fixed standard yet. I might just go the flash route until it's further developed :)

/Ozak