AltME groups: search

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/

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?

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

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

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.

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.

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.

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.

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?

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.

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.

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.

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

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.

http://www.whatwg.org/specs/web-socket-protocol/


Doesn't look very difficult .. if you need it, start a bounty for 
it

I presume that a web socket "function" will block all of Cheyenne 
until it is completed.

well, I'm planning to make an turn based online game, but not inside 
a browser, client will be a separate rebol application. it will be 
connected to a web socket, and player did somthing it will be sent 
to all other players

Sounds like I can forgo the sendmail.rsp script which a user might 
damage and just use a web socket instead

@Graham: you are using web sockets for a wierd job. The shortest 
explanaiton for web socket is: it is the way to trigger an event 
on the client side from the server side via already open tcp (http) 
connection. ofcourse that connection is full duplex, client and server 
both can send a utf8 encoded (currently no binary) string messages 
anytime.

I was thnking of using a web socket connection to cause Cheyenne 
to reload its configuration

FYI: I've been doing some web sockets testing with Cheyenne. It seems 
that the specification is still a fast moving target. The browsers 
are trying to keep up, but server implementations (like Cheyenne) 
are breaking. For example, the Cheyenne web socket samples work with 
Chrome 12 on Ubuntu, but not with Chrome 14 or Safari 5.1 on Windows. 
I'm going to try the iPad tomorrow.

A good site to test web socket support in your browser is http://websocketstest.com.
It will even show the specification draft that your browser supports. 
It's different in Chrome 12 and Chrome 14.

Thank you. I'll try.

What I'm working on is, to poll a database table and send some changes 
to a client on a web socket. polling should not block Cheyenne of 
course.

My plan is, adding database to Cheyenne config, poll in an aysnc 
way (jobs, task-master, etc.) and send something to clients over 
web socket.

Web socket + database query: it won't block if you transfer the query 
job to an RSP script. See the ws demo app: %www/ws-app/ws-test-app.r 
and the back-end RSP script: %www/ws.rsp