Implementing comet long polling...

[Ron]

Alright added SHA-1 and Base64 encode and decoding. Also I've added "init" calls to prevent the need for continually creating new objects by allowing hash object reuse.

require('bit')

local md5 = bit.newMD5()
md5:init()
md5:update("The quick brown fox ")
md5:update("jumps over the lazy dog.")

print(md5:final())

local sha1 = bit.newSHA1()

sha1:init()
sha1:update("The quick brown fox jumps over the lazy dog")
print(sha1:final())

local str = "The quick brown fox jumps over the lazy dog"

local es= bit.base64encode(str)

print(es)

local ds = bit.base64decode(es)

print(ds)

[shaun5]

Ron: Thanks for the bit.dll. Using the WebSocket API, I know I can correctly generate the protocol 6 response. I've got Chrome and Firefox upgrading the connection from connecting to open, but I can't send or receive a response yet. Safari and Mobile Safari still work nicely...

[shaun5]

Ron: Poor assumptions, lead me to wrong conclusions... I have been receiving data from Protocol 6 all along.

Both protocol 0 and 6 start with HTTP headers terminated with \r\n. Once protocol 0 is 'open', the data is formatted in both directions as: HEX 00 .. data string .. HEX FF. Protocol 6 data is different. Is just using STREAM vs. a PARSER going to be the best option? Or is there a way to start with the \r\n parser and once the protocol is determined for the client the parser is changed according to the requirements for each client??

Adding support for both protocols is going to take some work! A derivative of protocol 6 is probably the future, so it is probably a worthwhile improvement...

[Ron]

I think stream will be your best bet in this case.

[shaun5]

Update: Everything working... Ron, is there a way to set up the webserver to forward a port 80 request with a ws. prefix to my websocket transport listening on port 8080?

[shaun5]

Update (if anyone is interested): I've added event triggering. This eliminates ajax_sendevent.lhtml for my websocket clients. Not sure if there is anything to be gained, but it seemed odd to not use the open websocket connection for two way communication.

[Mike C]

hi shaun, do you have any screen shots and code to post?

mike

[shaun5]

Mike: I can't think of any relevant screen shots, just tell me what you are looking for and I'll help. Did you try my posted example? Do you have a working webpage for Girder? If so, can you post it?

Except for adding the files, there is zero configuration in Girder. Unfortunately, I don't think the Gider collective has standardized on how the javascript should be written, so there is some adaptation (or conversion to my methods) to be done there. I was waiting to write it up in hope Ron discovers or shows us (me) a way to forward the websocket.

[Ron]

you could open a http request with curl inside a webpage and forward it to the websocket...

[shaun5]

Ron: Everything I know regarding port redirection is server specific (IIS or Apache). I didn't think the Girder webserver is either, what is it?