World: r3wp

we can't listen ..

Even if you use "Run as administrator" on REBOL binary?

I created a listen on 8010
and still same error

If you're not running on port 80, you need to add the port number 
to the ws:// URL in ws.html. Tested here, it fixes the "conn closed" 
issue.

var conn = new WebSocket("ws://localhost:8000/ws.rsp")

oh ...

makes sense

Terry: after taking the time to think about your comments regarding 
how web sockets should be integrated in UniServe & task-master, it 
starts to make sense and it inspires me on how it could be done and 
how the framework could look like. I'm writing a few specs on paper 
and will maybe implement a prototype tomorrow. This web sockets stuff 
is really going to be exiting after all. ;-)

Yay!

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.

<snip>

EOM: "\n"
; prints messages to console.
verbose: false
; opens port
io-port: open/no-wait tcp://:7001
clients: []
; numbers of clients
nc: 0
; max clients limit
mc: 50

..... 

forever [


;Events are periodical functions.. checking if a website is still 
up etc. Add a wait state to prevent excessive CPU usage
;wait .02 
;if not empty? %events.txt [do load %events.txt]

either none? (wait [ .01 io-port])
            [ clients: head clients ] [
		
            print "a user is connecting"
            either ( nc < mc ) [
            append clients make object! [
                        port: first io-port
                            ]
            nc: nc + 1
            respond rejoin ["Connected to ROCKSTaR" EOM ]

... 

etc

My goal is to be able to write the server side of a web app like 
this one (2k concurrent users on average)  http://www.onlinegames.com/basketball/
using Cheyenne & a web sockets framework with minimal efforts and 
good scalability.

Yeah, was playing that.. I suck.

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.

Im guessing null with websockets as 0xFF ?

uh , I just wrote a long reply here but it got eaten by the altme... 
in short:


I was away for few days. Thanks a lot for all the comments and good 
info above!! Doc solved the problem also!


About websocket.. wow wow wowoww!!! this will be very very cool to 
have!! I have made chat via chat server -> flash -> js before and 
COMET is a total mess and hack on the client side (it's a miracle 
they made it work, so many tricks in there to work)

The problem with markers is that you can't have the marker appearing 
in the data, so you have to check all data for it and escape it when 
found

It's much more efficient when you can tell the size of the data in 
advance

But indeed this seems to be lost on Internet protocols

http uses data size

Jetty jumps on the websocket bandwagon

http://ajaxian.com/archives/jetty-introduces-websocket-support-relunctantly

Cheyenne as a "Kaazing Killer" makes it to #3 on Google :)

Hehe :-)

Looks like I'm not the only one ranting about web sockets protocol 
specifications : http://blogs.webtide.com/gregw/entry/how_to_improve_websocket

To get the websocket demo  working am I accessing "ws://localhost/ws.html"?


Using http:// does not work but ws:// redirects me to google search 
of url


I'm using the latest svn version...starting from icon...using chrome 
4

If Chyenne is running on port 80, then 

http://localhost/ws.html

and you should see a javascript button

If you're not running on port 80, then you need to modify the ws.html 
file and add the port number in the ws://localhost part ...

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

You'd need to implement the client side protocol in REBOL

I'm on port 80 ...


I see the button and get the hello world message popup as well as 
a "comm opened" popup at start...


I was trying to get Terry's demo to work but his "Drag this" does 
not seem to do anything...

Anyone try out Terry's?

Also could not get  ws.rsp to work..."page cannot be displayed"

ws.rsp script is supposed to be accessed only through web sockets 
: ws://localhost/ws.rsp

I get redirected to google search with > ws://localhost/ws.rsp

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.

browser address <field>

doh...thanks will have a look.

With my demo, when you click the "Make draggable" button, it sends 
a message to Cheyenne via the websocket.. the response is some JS 
that makes the box draggable.

Doc.. any more thoughts on the ws:// protocol system? As it sits 
now, it's a glorified AJAX call.

It keeps the connection open, doesn't it?

the connection is open, but RSP is stateless

Hm, yes, as Doc said, the server model needs to change

hey doc.. one issue with a forever loop is the ability to listen 
for new incoming messages from the client.. How would you handle 
that? Put them in a buffer, and check it during the loop?

Does Cheyenne have equivalents of Apache's mod_expires and mod_deflate?

It does compression, in any case

It's more the expiry dates for jpeg files that I'm worried about 
at the moment.

Terry, I can't get the box to drag..

It won't drag unless the ws.rsp page does more than just echo stuff 
..

you require my updated ws.rsp file.. see above.

Not sure to understand what you mean Terry, ws.rsp is receiving all 
the incoming messages.

Anyway, I'm working on a improved framework being able to handle 
connect/deconnect client events and giving access to all client ports 
connected to a given ws:// URL.

the connection is open, but RSP is stateless

 If you want to make it stateful, just store the data in session, 
 file, database, whatever...Most of RSP API is still working with 
 web sockets (response object methods will have no effect).