I'm looking at the jssocket source and it say's that as3 binary sockets can prefix messages with a size. I cant' find this in adobe's documentation, anyone have a link to where that's documented? Also, from what I can tell the mongrel2 parser needs flash sockets to send null terminated messages Is that correct?. I see that jsSocket.hx adds this to each message it sends. Chris
On Fri, Sep 24, 2010 at 01:10:09PM -0700, snacktime wrote: > I'm looking at the jssocket source and it say's that as3 binary > sockets can prefix messages with a size. I cant' find this in adobe's > documentation, anyone have a link to where that's documented? Hey snacktime, long time eh? Yeah I'm actually not too sure about the protocol other than what I get off the wire, but my experimentation said that the size prefixed version of the protocol wasn't as pervasive and supported, so I did the other way. IIRC there was another problem with it and parsing. > Also, from what I can tell the mongrel2 parser needs flash sockets to > send null terminated messages Is that correct?. I see that > jsSocket.hx adds this to each message it sends. Yep, that's correct. Additionally, Mongrel2 just adopts the stance that you're going to use a fixed protocol of: @route json_stuff \0 The @ is sort of optional but I recommend it. The Json stuff should be hash usually, since that's what handlers expect, and it's \0 terminated. The really stupid part is then what you get back is nearly the same thing but in a base64 wrapper. Boggles the mind how they came up with such an asymmetrical format. Check out the examples/chat/ to see how it's all being used. -- Zed A. Shaw http://zedshaw.com/
> The really stupid part is then what you get back is nearly the same > thing but in a base64 wrapper. Boggles the mind how they came up with > such an asymmetrical format. > So I just hit this and I think it's the toString call on a ByteArray that's returning base64. I'm playing around with some alternate ways to do this. Maybe splice the byte array first then read it using ReadMultiByte, which will return ascii. Or just read the whole thing as an ascii string and then split it. Chris
On Mon, Sep 27, 2010 at 03:04:56PM -0700, snacktime wrote: > > The really stupid part is then what you get back is nearly the same > > thing but in a base64 wrapper. Boggles the mind how they came up with > > such an asymmetrical format. > > > > So I just hit this and I think it's the toString call on a ByteArray > that's returning base64. I'm playing around with some alternate ways > to do this. Maybe splice the byte array first then read it using > ReadMultiByte, which will return ascii. Or just read the whole thing > as an ascii string and then split it. Actually, it's something about the flash protocol that requires this. I think it's that the Flash client actually tries to interpret any XML in the payload, so you b64 it to avoid that. Sadly I just keep it the way that works and leave it. -- Zed A. Shaw http://zedshaw.com/
> Actually, it's something about the flash protocol that requires this. I > think it's that the Flash client actually tries to interpret any XML in > the payload, so you b64 it to avoid that. Sadly I just keep it the way > that works and leave it. I kind of started to figure out that there isn't a way to get ascii straight out of the socket. But the insane thing is there is no base64 decoder in flash. There is a semi adobe supported one in core lib from what one of our flash guys just told me. Chris
On Mon, Sep 27, 2010 at 05:48:46PM -0700, snacktime wrote: > > Actually, it's something about the flash protocol that requires this. I > > think it's that the Flash client actually tries to interpret any XML in > > the payload, so you b64 it to avoid that. Sadly I just keep it the way > > that works and leave it. > > I kind of started to figure out that there isn't a way to get ascii > straight out of the socket. But the insane thing is there is no > base64 decoder in flash. There is a semi adobe supported one in core > lib from what one of our flash guys just told me. Ahhhh, that's the thing, you b64 it to keep flash from touching the response, even though it doesn't touch what's sent. Basically it's a piece of crap but it works so just accept it until websockets come. -- Zed A. Shaw http://zedshaw.com/
> Ahhhh, that's the thing, you b64 it to keep flash from touching the > response, even though it doesn't touch what's sent. Basically it's a > piece of crap but it works so just accept it until websockets come. > So there is something else going on here we aren't aware of. When I use the exact same socket code just with a different host/port and request (GET / \n\r), the socket gives me back ascii text. I'm also looking at other flash codebases that deal with ascii protocols and they all get back ascii text, not the base64 encoded crap. Chris
On Tue, Sep 28, 2010 at 12:22 PM, snacktime <snacktime@gmail.com> wrote: >> Ahhhh, that's the thing, you b64 it to keep flash from touching the >> response, even though it doesn't touch what's sent. Basically it's a >> piece of crap but it works so just accept it until websockets come. >> > > So there is something else going on here we aren't aware of. When I > use the exact same socket code just with a different host/port and > request (GET / \n\r), the socket gives me back ascii text. I'm also > looking at other flash codebases that deal with ascii protocols and > they all get back ascii text, not the base64 encoded crap. > > Chris > Ah so the server is base64 encoding the message. Wouldn't it make more sense to have a custom version of the client that uses a more sane protocol? Or at least an option for mongrel2 to disable base64 encoding. Base64 in flash is expensive, it's not something you want to do all the time without good reason. Chris
On Tue, Sep 28, 2010 at 12:33:47PM -0700, snacktime wrote: > Ah so the server is base64 encoding the message. Wouldn't it make > more sense to have a custom version of the client that uses a more > sane protocol? Or at least an option for mongrel2 to disable base64 > encoding. Base64 in flash is expensive, it's not something you want > to do all the time without good reason. Nah, this works, just go with it until we get websockets. I mean, it's just how jsSockets work, and they work fine. -- Zed A. Shaw http://zedshaw.com/
On Tue, Sep 28, 2010 at 12:38 PM, Zed A. Shaw <zedshaw@zedshaw.com> wrote: > On Tue, Sep 28, 2010 at 12:33:47PM -0700, snacktime wrote: >> Ah so the server is base64 encoding the message. Wouldn't it make >> more sense to have a custom version of the client that uses a more >> sane protocol? Or at least an option for mongrel2 to disable base64 >> encoding. Base64 in flash is expensive, it's not something you want >> to do all the time without good reason. > > Nah, this works, just go with it until we get websockets. I mean, it's > just how jsSockets work, and they work fine. > I'm not using javascript, just flash. I'm looking at mongrel2 as a possible server for handling flash socket connections. I don't mind having some modifications to mongrel2 to make it work for us, in this case it was a one liner to handler.c. If everything else ends up working for us, I might just add a flash handler that prefixes the message with a length instead of using a null delimiter, which would be more efficient for flash and also let us handle binary data better. Chris > -- > Zed A. Shaw > http://zedshaw.com/ >
> I'm not using javascript, just flash. I'm looking at mongrel2 as a > possible server for handling flash socket connections. I don't mind > having some modifications to mongrel2 to make it work for us, in this > case it was a one liner to handler.c. If everything else ends up > working for us, I might just add a flash handler that prefixes the > message with a length instead of using a null delimiter, which would > be more efficient for flash and also let us handle binary data better. Actually I take the binary stuff back, I can't think of anything that we couldn't use http for when it comes to binary files. I do have one question about this line in the parser: SocketJSON = ("@" rel_path ) >mark %request_path " {" any** "\0" @json @done; What bad things could happen if you remove " {" ? Chris
On Tue, Sep 28, 2010 at 01:24:30PM -0700, snacktime wrote: > > I'm not using javascript, just flash. I'm looking at mongrel2 as a > > possible server for handling flash socket connections. I don't mind > > having some modifications to mongrel2 to make it work for us, in this > > case it was a one liner to handler.c. If everything else ends up > > working for us, I might just add a flash handler that prefixes the > > message with a length instead of using a null delimiter, which would > > be more efficient for flash and also let us handle binary data better. > > Actually I take the binary stuff back, I can't think of anything that > we couldn't use http for when it comes to binary files. Exactly. :-) > I do have one question about this line in the parser: > > SocketJSON = ("@" rel_path ) >mark %request_path " {" any** "\0" @json @done; > > What bad things could happen if you remove " {" ? Then it wouldn't be a json message that backend handlers can reliably deal with. It's meant to be a message queue, not a completely flexible "send anything I want" socket system. The idea is you use this to do data and metadata, but actual file transfers and binary stuff is better done with HTTP. To make it easy on everyone we standardize at always sending json to identify requests. But, that line of code does show me to be a liar about being able to use / to prefix json message. Hmmm. Anyway, what is it *exactly* you're trying to do? Maybe take it off list so that you can tell me without telling everyone. From my past experiences tiny little emails with little bits of questions make it hard to actually figure out what you want, so maybe start with what you're doing exactly, show code examples of what you want, and lay out what you need instead. -- Zed A. Shaw http://zedshaw.com/