World: r3wp

Not familiar with Comet .. except as the name of my dog :)

So, if it opens a stateful connection, then I guess it is less able 
to scale to lots of users

And are people then running BEEP over web sockets?

It opens up the possibility to do similar things, yes, while still 
being able to fool firewalls

It has a good chance of fooling the firewalls because it starts as 
a normal HTTP connection

Since it's being standardised as web technology, there will be a 
big social barrier for firewalls to start blocking it

As a continuous connection, it's less scalable than regular HTTP, 
yes, but it's more scalable than Comet, which needs two connections 
for bidirectional communication, and other hacks

It scales better, as only a single connection is used.. in fact, 
Google is pushing it with Chrome for that very reason.

Comet is a diverse collection of hacks to create longer-term connections 
with Ajax

after the initial http handshake, there's no http headers included

Here's a good primer

http://www.indicthreads.com/3625/html-5-websocket-cracks-the-http-request-response-barrier/

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.

SVN r45 : Web Sockets support


FEAT: experimental Web Sockets support added. (See %www/ws.html and 
%www/ws.rsp)
FIX: regression on bad HTTP request filtering. (Thanks to sqlab)
FIX: minor code clean-ups.

You'll need Chrome 4 to be able to use web sockets (don't know about 
other browsers).

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).

Server-side 'connect and 'close sockets events are missing. Not sure 
how easy it will be to add them to the RSP application model. More 
generaly, the web sockets require a shift in the whole application 
model, the RSP engine is tuned to request/response model, not client/server. 
I'm not even sure that such server can be built in a efficient way 
with REBOL without multi-threading support (can't share port! values 
between processes).

Just think about how a minimalistic multi-user chat app could be 
built using web sockets. The application code needs to be able to 
access all the existing connected sockets to broadcast user posts, 
but these sockets are connected to the main process (UniServe) while 
the application code is run in worker processes...Having everything 
in one process would solve that but you can't run any scalable app 
with such model (beyong just passing messages between sockets). That's 
where mutlti-threading would have been useful...

We should push for R3 finishing task! datatype then, if you need 
threading :-)

Does this mean you can now  more easily write a web control panel?

And does it make it easier to use Cheyenne's mail server?

I downloaded Chrome 4, and when I access the ws.html, I get a chrome 
requester that says "Conn closed" before I  even get a chance to 
click on the "Send Message" button.

Anyone else tried this?

SVN r45 ?

is there a link?

code.google.com

yeah, just found it

Doc, I'm not sure RSP is the proper handler for websockets.  The 
earlier stuff i was working on used a forever loop. Isn't RSP more 
traditional stateless?

working fine here Graham

I'm not even sure that such server can be built in a efficient way 
with REBOL without multi-threading support (can't share port! values 
between processes).

This is where i hit the wall in the past.  (Look back in this group 
to Nov 8th and prior posts)
 

Isn't "just passing messages between sockets" enough? What else did 
you have in mind?
My thought would be a business layer managing sockets? no?


Anyway.. nice work.  I told you it would only take a couple of  hours 
for a guru  :)

Graham: you should check if your server is reachable on this URL 
: http://localhost/ws.rsp(it should if you're using the config file 
from SVN). 


Web Control Panel : yes, it's easier with web sockets than with COMET 
approach, but it's not a show stopper anyway.

Mail server : it could make it easier if you're using a client supporting 
web sockets.

Can i put a forever loop in RSP, and how would i push the buffer?

No you can't, it won't work (RSP engine use a request/response model), 
but even if you could, that would mean one process per client connection, 
definitely not scalable.

Strikes me as a new Uniserve service

My thought would be a business layer managing sockets?

 If you want a kind of bridging server (web sockets<=> Server <=> 
 TCP), there's already existing products doing that like http://www.kaazing.com/products/kaazing-websocket-gateway

Well, there's already existing web servers as well. .That's not the 
point.

This could be a Kaazing killer

(Watch that pop to the top of Google when searching 'Kaazing' :)

Needs to be in a forever loop somewhere. I'm guessing a service (or 
protocol.. can't remember which)
so that you can connect and to this.. 

forever [

do %somehandler.r

]

where somehandler.r could manage the connections? no?

so the "polling" aspect is moved from the client -> server.. to an 
internal script via multiple forevers 
or sumtin' like that ?

something like taskmaster?

I don't get your "forever loop" approach, UniServe uses an event 
loop.

I'm looking for some old experiments

but wouldn't it just be standard on-connected , on-received  protocol 
handlers anyway?

it requires some kind of null event at the end of each incoming message

install-service [

    	name: 'test
    	port-id: 3001
	stop-at: "^@"

(that's the standard Flash EOF)

on-received: func [data][ 
	theIP: client/remote-ip
	do %websockethandler.r	
]

If you're trying to ask if a gateway like Kazaaing can be built using 
UniServe, the answer is : sure and it will be scalable.

I think the hard part is done already.. dealing with ws://

(maybe wss:// might be a little trickier :)