AltME groups: search

I changed the Red 0MQ interface to optimise the memory use during 
receiving of messages:

http://red.esperconsultancy.nl/Red-ZeroMQ-binding/info/2a1541af57


SEND and RECEIVE have been renamed to send-string and receive-string, 
because they currently handle messages as UTF-8 text. When Red gets 
a binary! type, versions for binary messages will be added, and there 
will probably be type agnostic SEND and RECEIVE wrappers again. Previously, 
you used

message: receive socket


to receive a string message. Now you pass a premade string! (similar 
to call/output in R2):

message: ""
receive-string socket message


This means that you can choose between creating new strings for each 
message (with COPY) or reusing the same string. In the latter case, 
some Red/System code in receive-string makes sure that no extra Red 
memory is used, and that all used system and 0MQ memory is freed 
again. By optimising memory use, this also improves performance of 
message throughput.

Kaj: 
love your r2 bindings for zeromq 
i've been trying to implement the push-pull ventilator example

ventilator:
REBOL []

do %zmq.r

pool: zmq/new-pool 1
socket: zmq/open pool zmq/push
zmq/serve socket tcp://*:5555

ventilate: func[][
  print "sending"
  u: form time/now/precise
  zmq/send socket to-binary u 0
]

wait 0:00:60 [
  ventilate
]

worker:
REBOL []

do %zmq.r

pool: zmq/new-pool 1
socket: zmq/open pool zmq/pull
zmq/connect socket tcp://*:5555

data: copy #{}

forever [
  zmq/receive socket data 0
  prin ["."] 
  print to-string data
]

...but the worker crashes

I can see where the crash happens.

It happens in or just before an awake function, when the peer closes 
the socket.


On_Data: func [port] [action-time: now con: port msg: copy: copy 
port 
	if any [none? msg empty? msg] [print ... 

and the print is not evaluated.

no, just a plain console application accepting tcp socket connections 
and data

I did not see this with rebcmd2..55.3.1.alpha, but maybe I did not 
test with enough traffic from more than one sender at the same time.

I just remember that some of the interim releases were not stable 
enough regarding read/lines, so I was waiting for a (near) final 
release for intensive testing.


Now I am checking, if different behaviour of the sender has some 
influence.

Normally at least one sender establishes a permanent connection, 
but most sender open a connection, do their communication  and close 
the socket at the end.

That's the reason, why I know, that the crash happens after closing 
the socket.  The last message was always from one of the senders 
with a one time connection. He got his answer, but the receiver did 
not print the message, that the remote socket was closed.

Maybe it has to do with timing and or GC problems, as the crash happens 
mostly at a time, when there is more traffic, but never when there 
is always  continuous communication. When I play back the communication 
without interruption, there is no crash.

I'm trying to learn how to make tcp servers, reading this rebol doc: 
file:///C:/SDK/docs/core23/rebolcore-13.html#section-14

Why am I getting this error:

>> listen: open tcp://:8001
** Access Error: Error opening socket listen port
** Near: listen: open tcp://:8001

Turning the firewall off does not help.

Lous:

your port  is already opened either by an opther application or by 
this rebol instance as you can connect to.

So either use an other port number or close your listen socket before 
opening again

Anton, Olds, sqlab, thanks for the help.

Here I paste directly from the docs:

>> server-port: open/lines tcp://:4321
** Access Error: Error opening socket listen port
** Near: server-port: open/lines tcp://:4321
>>


Could there be something wrong with the way XP is set up that is 
causing this?

Can someone help me with this?

>> open tcp://:12345
>> open tcp://:12345
** Access Error: Error opening socket listen port
** Near: open tcp://:12345
>> a: 12345
== 12345
>> open tcp://:a
>> open tcp://:a
>>

>> a: 1234
== 1234
>> p: open join tcp://: a
>> close p
>> p: open join tcp://: a
>> p: open join tcp://: a
** Access Error: Error opening socket listen port
** Near: p: open join tcp://: a
>> close p

can use a ws socket or whatever, and skip opening port 993 on the 
client as well.

thanks for the quick answers! you guys are great


I'm building a function that computes the challenging code for  web 
socket  protocol, 

It uses unsigned 32 bit integer, so I use money instead of integer, 
to avoid overflow.

The bug was my fault, I was using a wrong variable name.
Thanks all for the help.

The complete (working) function to calculate the challenging code 
server side in web socket protocol is:

ws-chall: funct [header [string!]] [		
	
	cnt: funct [k] [
		n: copy "" 
		ns: 0 
		repeat x k [
			if all [x >= #"0" x <= #"9"][
				append n x
			] 
			if x = #" " [
				ns: ns + 1
			]
		]
		if ns = 0 [
			return none
		]			
		(to decimal! n) / ns
	]
	
	int-2-char: funct [n [integer! decimal!]] [
		;n: to decimal! n
		head insert insert insert insert make string! 4
			to char! n / 16777216
			to char! (n // 16777216) / 65536 
			to char! (n // 65536) / 256
			to char! n // 256
	]

	attempt [
		t: parse/all replace/all header crlf lf "^/"

  l: copy [] repeat x t [if n: find x ":" [insert tail l reduce [copy/part 
  x (index? n) - 1 next n]]] l: head l
		k1: next select l "Sec-WebSocket-Key1"
		k2: next select l "Sec-WebSocket-Key2"
		k3: next next find header "^/^/"
		aux1: cnt k1
		aux2: cnt k2
	]

	if any [none? aux1 none? aux2 none? k3] [return ""]

 to-string checksum/method rejoin [int-2-char aux1 int-2-char aux2 
 k3] 'md5		
]

the protocol is described here: http://www.whatwg.org/specs/web-socket-protocol/

Have you checked whether MySQL is configured properly to accept tcp-requests 
instead of only socket-based connections?

Taygeta's is based upon BSD socket interface, but they recommend 
that if the host already provides a stack, it is only necessary to 
write the inteface.

ntpdate says socket is being used

So, the first strange thing is that I get a: "Bind socket to interface: 
No such device".

Gettting an Access Error: Error opening socket listening port

MaxV, It is possible to use call, but then the scripit would be executing 
like CGI. I wanted to pipe two REBOL scripts from the command line 
and have the first script periodically send data to the second. Of 
course I could use a socket, but that's a little more complex.

mysql: some hosts only allow socket access and not tcp access to 
mysql (because that's the default config for some distros.) but, 
that's something that they can enable without problems.

My X Internet talk went well last night, lots of enthusiasm by IT 
professionals there.  Might even have snagged a sizeable government 
project which needs technical guidance...you never know who's listening...;-) 
 (I will be out of socket till Sunday, for some R&R (REBOL and Relaxation 
is what that means)

Yes, surely parse can do it... I am just debating .. I am not sure 
if mongrell is really that awesome.


I was thinking that speedwise the upper bound of the http server 
is determined by socket handling and http parsing probably? Meaning 
that even if you have everything in ram and prepared you can't serve 
more thatn that. Cheyenne has a *very* high upper bound for a dynamic 
language (I was many times expressing my surprise and getting 250 
req/s was the reason I returned back to rebol with doing all webapps 
in it now).

IIRC, for a server I did, I had to use read-io, don't rememeber why 
but it made it simpler in a complex and timed server multi-port management 
loop (direct tcp socket handling).

I have some questions for our Flash experts:


1. Is it possible to open a plain socket from Flash to a remote host?
2. Can I modify the DOM of th browser from AS?

I just want to open a socket to the same domain the falsh was read 
from.

Is your Rebol dialect able to compile all AS stuff? I'm not interested 
in the graphics stuff but only in using Flash's socket stuff to do 
some networking code.

But wouldn't this be possible by provding a generic dialect framework 
that runs over a socket (maybe using R/S)? Apss just need to expose 
the service interface.

normally there is, but not always. 

Most socket connections are static, they stay connected for hours 
or longer.

can you imagine that not being able to know the current login name 
is case enough for REBOL not being used in multiuser office environments. 
 that is something which MUST be addressed in R3 its a simple call 
to the socket lib (IIRC) and if protected, then that info can force 
apps into being multi-user oriented.

You can implement SQL protocol with the knowledge of REBOL level 
stuff, plus e.g. extensions. For mySQL (socket based), you don't 
even need extensions. The only thing I can see is missing, is good 
enough docs ...

how can i inject request to the socket ?

Security extension, yes, removal of something - hehe, how uneducated 
imo :-) Is smtp so difficult to build? Having tcp socket is dangerous 
already, as I can build my custom smtp in script, and have server 
at the other end of the country, which listens on 8080 and doing 
smtp ....

but does Windows http/ftp API limit rebol free socket capabilities 
or not? :-)

The problem is that today REBOL is doing everything itself. It is 
making the socket connection, sending the GET command, etc. In the 
process, it has to know everything about the proxy settings and do 
everything natively.


I am proposing adding new HTTP/FTP support that uses the Win32 API. 
No more socket communication within REBOL -- instead, Win32 does 
everything, including interacting with proxies.

(When I say "No more socket communication", I mean that these options 
will not use the REBOL networking stack)

so native raw rebol socket low-level communication will be still 
possible, right?

as my understanding goes, raw socket remain, so if someone wants 
his http scheme, he can still program one in rebol ....

IIRC via set-modes/get-modes, you can know what adapter is involved. 
I am afraid there is no other way how to prevent this. Opening a 
socket is OS thing imo, and I wonder if C socket functions allow 
you to choose your device?

It can be done at the C socket level, unfortunately, I don't know 
any way of doing that from REBOL.  I guess that's not supported in 
the current REBOL port!.

Worked out the other issue.. Flash requires crossdomain.xml file 
to be delivered up by Cheyenne when running Flash that uses xml.Socket 
(like RASH).
Butt it's working well now.. and very cool. 

Works like this.. I run my local copy of Framewerks with embedded 
Cheyenne server, and park the GUI on any server (always accessible, 
single point of bug fixing etc.) for all to use.. currently it's 
here  http://kommonwealth.com/exper/gui.html


Now, it wont work for you 'cuz you're not running framewerks.. but 
if you were..  you could type into the box "codes" and it would open 
the RASH code file, on your desktop, using your favorite text editor. 
  

But wait.. there's more... 

In my local code.txt file i have the following line

PnG "testing" ][bout: {<pre>ok this works</pre>} makeXML ['DISPLAY 
'MSG "testing works here"]]


So when I open another browser, and point it to http://localhost/
testing  that line is fired (more on all this later).. 

Which does two things.. it outputs "ok this woks" to this second 
localhost page .. BUT (and this is the cool part)

it sends the "testing works here" into the panel on the first kommonwealth 
page. 

In other words, Im able to PUSH data to the remote page at ANY TIME.. 
  this will make for the ultimate in portal pages. 

And.. if that's not enough, Im able to pass messages to the DOM via 
javascript to the kommonwealth page as well. 

Allowing things like sliding in panels.. fading div elements moving 
images.. whatever.


So.. remote page can manipulate my computer.. run apps, do any Rebol, 
reboot .. whatever.. and the local desktop can manipulate a remote 
web page.

Finally.

Hey Doc, how would you deal with an async socket (or .dll) that received 
events allowing realtime updates on a Cheyenne web page?

ie: user clicks a button on a page, send http to Cheyenne.. Cheyenne 
pushes a message via the socket, receives a response, and pushes 
the result back to the page.

I want to unify communications using Cheyenne (Rebol) as the middleware, 
pulling and pushing info through and to each other

ie: an event message from Freeswitch is processed via xml socket, 
processed, and pushed to a web page via comet / ajax.. and back again..

This PHP code works fine..

<?php
 
 $password = "ClueCon";
 $port = "8021";
 $host = "127.0.0.1";
 
 function event_socket_create($host, $port, $password) {
     $fp = fsockopen($host, $port, $errno, $errdesc) 
       or die("Connection to $host failed");
     socket_set_blocking($fp,false);
     
     if ($fp) {
         while (!feof($fp)) {
            $buffer = fgets($fp, 1024);
            usleep(100); //allow time for reponse
            if (trim($buffer) == "Content-Type: auth/request") {
               fputs($fp, "auth $password\n\n");
               break;
            }
         }
         return $fp;
     }
     else {
         return false;
     }           
 }
 
 
 function event_socket_request($fp, $cmd) {
    
     if ($fp) {    
         fputs($fp, $cmd."\n\n");    
         usleep(100); //allow time for reponse
         
         $response = "";
         $i = 0;
         $contentlength = 0;
         while (!feof($fp)) {
            $buffer = fgets($fp, 4096);
            if ($contentlength > 0) {
               $response .= $buffer."<br>";
            }
            

            if ($contentlength == 0) { //if contentlenght is already don't process 
            again

                if (strlen(trim($buffer)) > 0) { //run only if buffer has content
                    $temparray = split(":", trim($buffer));
                    if ($temparray[0] == "Content-Length") {
                       $contentlength = trim($temparray[1]);
                    }
                }
            }
            
            usleep(100); //allow time for reponse
            

            //optional because of script timeout //don't let while loop become 
            endless
            if ($i > 10000) { break; } 
            
            if ($contentlength > 0) { //is contentlength set
                //stop reading if all content has been read.
                if (strlen($response) >= $contentlength) {  
                   break;
                }
            }
            $i++;
         }
         
         return $response;
     }
     else {
       echo "no handle";
     }
 }
 
 $fp = event_socket_create($host, $port, $password);
 $cmd = "api show dialplan";
 $response = event_socket_request($fp, $cmd);
 echo $response; 
 fclose($fp);

IMO HTTP sucks. Since years people try to make stateless HTPP stateful. 
One just needs a simple socket and than handle everything via a multiplexed 
channel system through this.

I imagine you could build a web socket protocol with Cheyenne in 
a few hours.. would take me a week

The problem I've always had with Cheyene and Uniserve services was 
the 'disconnect' between the two.. ie: having a uniserve 'socket' 
connect with an 'http' connection and vice-versa.  The ws:// protocol 
was what i was looking for.. the best of both worlds. Deliver some 
hypertext, then push data to javascript in the browser.

It's pretty straight-forward.. check out this PHP web socket server 
.. 140 lines

http://code.google.com/p/phpwebsocket/source/browse/trunk/phpwebsocket/server.php

FYI: I've implemented the web socket protocol in Cheyenne last night 
(not released yet) but I still need to figure out how to properly 
interface incoming data frames with the RSP engine.

i still need to figure out how to interface incoming data frames 
with the RSP engine

That's where my Cheyenne websockets attempts hit the fan. Not so 
much the RSP, buf from a tcp socket to http and back again.

Currently, your web socket URL must point to an existing RSP script 
(or a path that translates to a RSP file). The included %ws.rsp script 
is just a simple echo service.

Once connected, all the web socket traffic is directed to the starting 
RSP script, where you can implement your own application specific 
protocol and action dispatching while benefiting from the RSP webapps 
features (like the webapp filesystem structure with private/public 
folders).

Here's quick demo of pushing javascript back for eval

---------WS.html--------------


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
	<title>Welcome!</title>
	

<script src='http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js'</script>

<script src='http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/jquery-ui.min.js'</script>	

</head>
<body>
<center>
<h2>Web Socket test page</h2>

<script>
var conn = new WebSocket("ws://localhost/ws.rsp")

conn.onopen = function(evt) {
 alert("Conn opened");
}
conn.onmessage = function(evt) {
 eval(evt.data); 
 }
conn.onclose = function(evt) {
 alert("Conn closed"); 
}


</script>

<button onClick="conn.send('Hello World');"> Send Message </button>
<button onclick="conn.send('makedrag');"> Make it drag</button>
</center>


<div id="test" style="height:100px;width:100px;border: 1px solid 
grey">MAKE ME DRAGGABLE</div>
</body>
</html>

-------WS.rsp------


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
	<title>Welcome!</title>
	

<script src='http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js'</script>

<script src='http://ajax.googleapis.com/ajax/libs/jqueryui/1.7.2/jquery-ui.min.js'</script>	

</head>
<body>
<center>
<h2>Web Socket test page</h2>

<script>
var conn = new WebSocket("ws://localhost/ws.rsp")

conn.onopen = function(evt) {
 alert("Conn opened");
}
conn.onmessage = function(evt) {
 eval(evt.data); 
 }
conn.onclose = function(evt) {
 alert("Conn closed"); 
}


</script>

<button onClick="conn.send('Hello World');"> Send Message </button>
<button onclick="conn.send('makedrag');"> Make it drag</button>
</center>


<div id="test" style="height:100px;width:100px;border: 1px solid 
grey">MAKE ME DRAGGABLE</div>
</body>
</html>

WS.rsp  should look like this

<%

;-- RSP API web sockets specific changes --
;

;   request/web-socket? => true if this is an incoming socket message, 
false if it's HTTP.
;   request/content/data => contains the socket message (string!)

;-- just echo back the message
//prin request/content/data

inc: request/content/data
if inc = "makedrag" [prin "$('#test').draggable();"]  

if inc = "Hello World" [prin "alert('Hello back');"]
 
%>

Btw, the Internet Draft defining the web socket protocol (http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-54) 
is really badly written. In particular, algorithm descriptions are 
incredibly obfuscated. On the design side, a packet-oriented protocol 
not sending packet length (for text frames), rather relying on begin/end 
markers, is a surprizing choice to me.

And if i browse to http://localhost:8000/ws.html .. I see the web 
socket test page, and I get a Chrome alert saying that Conn closed.

I was looking at my old experiments.. and they date back to the pre 
Cheyenne, Uniserve days.

I simply created a traditional tcp socket to handle the tcp stuff, 
and Uniserve's http.r prot for http.

On the design side, a packet-oriented protocol not sending packet 
length (for text frames), rather relying on begin/end markers, is 
a surprizing choice to me.
 

I think this is pretty much standard.. 
From an Xml sockets in Flash article


send() - This method allows you to send a string of characters through 
the socket connection. While the string is usually in XML format 
it does not have to be. This string can either be constructed using 
the XML object within Flash, or manually if size permits. Flash will 
also automatically append the terminating null character for you.

Anyone got an example of how to connect to the web socket from a 
rebol client?

This URL is not be typed in your browser address, it's for the web 
socket object creation in javascript. Please, have a look in %www/ws.html.

Terry, wait to try the new web socket framework I'm working on. It 
should be ready tonight (if I find time to finish testing and debugging).

SVN r46 : web socket application framework released.

There's also now the ability to define a timer per socket application 
to generate server-side events (powered by my scheduler library).

Btw, you can test this socket app using the two test script (look 
at the source code to get an idea) :
http://localhost/ws.html
http://localhost/ws2.html

SVN r49 :

FEAT: socket's 'on-message event now receives also the client port 
as 2nd argument
FEAT: RSP session access added for socket apps.
FEAT: minor memory usage reduction in mod-rsp.r.
FIX: additional 'disconnect misspelling fixed in HTTPd.r.

do-task allows you to have multitasking in you web socket application. 
Internally, it  re-uses the task-master service and the RSP IPC system. 
That way, you can easily integrate one or several web socket service 
or applications in existing RSP scripts or webapps.

do-task in this example, sends the raw incoming data from the browser 
to a worker process using ws.rsp script to generate a response that 
is sent back to the web socket app (if a /on-done callback has been 
defined) or directly to the client browser.

SVN r50

FEAT: /on-done callback support added to 'do-task function in socket 
application.

FIX: socket application API now has more homogeneous argument passing 
(client port always first now).

What's the need to have timers in RSP script when you have it already 
in socket applications?

Ideally, I guess all the socket control scripting should be done 
within the 'socket-app.

I was thinking this would make a great proxy to a remote server for 
futher processing... but how to pass the arguments?

I think I'm lost (happens all the time).  Let's say I want to poll 
a remote web page for screen scraping (or remote php processing) 
every 2 seconds, and pass that to a specific port.. I would do this 
from the 'socket-app, no?

You would generate the timer events in the socket-app, pass the job 
to do to an RSP script, and use the /on-done handler to send the 
response to the client you want once the RSP script finished its 
work.


(this will work once I fix the issue with 'do-task calls from 'on-timer 
events).

SVN r51
FEAT: /ws-apps folders are now protected from direct access.

FEAT: modified socket apps source files are reloaded and used by 
new clients.

FIX:  web socket application's 'session object renamed to the more 
accurate 'rsp-session.
FIX:  'do-task calls now supported in 'on-timer handler.
FIX:  scheduler issue with deleted jobs.

That comes from the way web socket's connection are initiated, it 
starts like a simple HTTP GET request and the server is supposed 
to validate that request, check access authorization if required, 
etc... So, to avoid duplicating work, I choose to re-use RSP framework 
as much as possible. The initial ws:// URL must point to a valid 
RSP script so that the server can check, for example, RSP session 
cookie for access rights.

So, during the connection time, the target RSP script is not executed 
(unless you pass it a 'do-task in the 'on-connect handler). This 
target RSP gets associates with the opened socket until it's closed.

The last revision will auto-load your socket app if you've modified 
it, but only new incoming connections will use it. Established connection 
will still use the older version. Once every client disconnects from 
the old version, the old app version is dropped out.

Here's a little demo that allows you to drag an image, and once you 
stop dragging, sends it's position to a .r script via a socket. The 
script then sends a message to another image on the page to reset 
it's top and left position to match the dragged image, +100 px

The updated ws2.html page

http://pastebin.com/m4f61ffd7

the updated ws-test-app.r 

http://pastebin.com/m7c39d7c6

and the test.r script is (place in the Chyenne root)

rebol []
 
x: to-block system/script/args
 
left: x/left + 100 
top: x/top + 100

left: join left "px"
top: join top "px" 
 

data: rejoin [{$('#carl2').css("top", "} top {");} {$('#carl2').css("left", 
"} left {");}]

Terry's demo http://70.68.163.178/ws2.html

Doesn't work for me .. when I reach that page, it says "socket closed"
Dragging the image doesn't do anything.

I do get socket closed message too

What is supposed to happen is that when you drop the image, a message 
is sent to the socket and then some javascript executes to move the 
other image next to the one you drop .. something like that.

but the socket pointed to is on shinyrockets which is just a bigdaddy 
place holder page

here is a flash based websocket so you can support old browsers and 
use websockets now 8-)  http://github.com/gimite/web-socket-js

here is WebKit Web Socket design doc for anyone interested http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh

SVN r52
FEAT: web socket realtime chat demo added.

FEAT: changed socket application's SEND function specs to SEND client 
[port!] data [string!] (/with removed).

FIX:  timeout web socket issue clashing with HTTP keepalive timeouts. 
Web socket ports are no more timed out after 15sec.

Btw, the ws:// url still needs to point to a RSP script, but with 
the socket app container, the script doesn't need anymore to physically 
exists.

No, the bindind between the URL (/chat.rsp) and the web socket app 
(chat) is done in the httpd.cfg file with the 'socket-app keyword.

Got the chat demo running online. If you have a web socket enabled 
browser (ex: Chrome 4), go visit here : http://demo.cheyenne-server.org:8080/chat.html

For web socket apps, the advantage would be to not have to require 
'do-task to use the sync version of these protocols from a worker 
process. OTOH, that would put more burden on the main process lowering 
its scalability. So I've not decided yet, this would probably require 
good benchmarking first.

Cookies: well, it would be a nice addition to a real chat app, but 
the point in this demo is to show web socket usage, not to build 
a full-featured chat app. If you want to build a full chat app, you're 
free to take my demo code and extend it as far as you wish.

All in all doc, cheyenne sockets are very impressive. 
Couple of suggestions.. 

- Have a folder specifically for socket-apps that automatically get 
loaded into the http.conf file.. 

- Create a connection through PHP (if possible.. otherwise can just 
proxy, but adds lag)

Socket apps folder automatic loading : you still need to specify 
the mapping between URL and socket app, no ?

PHP connection: it should be possible with minimal modifications, 
but why would you want that? Is there any  significant PHP socket 
app yet ready to use? My goal in adding web sockets early in Cheyenne 
is to push developers to make nice apps in REBOL, not PHP.

That may be possible, but would be more complicated to support than 
web sockets as the server can't send data without getting a request. 
It will be hard to extend the web socket application framework without 
bloating it. Maybe a separated mod-comet would be a cleaner approach 
(but might duplicate a Iot of code in mod-socket). I will give it 
a look anyway, at least to estimate the time required to support 
it.

Here's some code that uses flash as a websocket proxy for browsers 
that don't support websockets
http://github.com/gimite/web-socket-js

Needs some tweaking, particularly with ports.

Web socket protocol is fully described here : http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol


Quick protocol overview : http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-68#section-1.2

Demo includes;
- websocket roundtrip timer
- ATOMDB query timer
- Example of changing a graphic when socket is closed.

- Font-face demo (another HTML 5 feature that allows ANY font in 
a webpage .. see the <style> on the page

I think not, older brosers only have xmlhttp (ajax) option, iframes 
and other comet like tricks but they can't do a socket .. I haven't 
seen what js.io does.. if you wanted to make a "pure" html chat without 
comet or polling you made JS that talked to invisible 1px flash and 
flash has XMLSocket or something like that. But I heard recently 
that it can be used for other things than xml ..

should have some default error trapping for socket-apps in the http.cfg 
file, no? One typo brings the whole server down.

Btw, keep in mind that defining a "standard" protocol above web sockets 
goes against its primary purpose : provide a general purpose packet-oriented 
communication channel. It would be like defining a "standard" protocol 
above TCP.


For practical usage with JS clients, JSON data format is the way 
to go. Don't forget that the web socket implementation in Cheyenne 
is partial, only TEXT frames are supported currently. I could add 
the binary support also, but I don't have a need for that for now. 
If someone has a *real* need for that, let me know.