Hi pd folks ! Billy Stiltner kindly forwarded me its recent posts, so I briefly suscribe to the list again only to reply to these questions regarding my old (and sole) publicly released pd tool.
On Thu, Nov 18, 2016 at 16:16 PM, Chris McCormick <chris at mccormick.cx> wrote: > The reason I didn't implement a websocket server is because I'd have to > figure out how to do sha hashing in pure-Pd and that is more effort > than I can put in right now. ... >> did you see the pd websocket server? >> it has some similar parts but looks way more complicated and is not >> vanilla plus it uses iemnettcp server or the onefrommr peach, would be >> nice >> to reduce the number of connections and vanilarize it just for a simple >> fudi thing > > Yeah it would be but the sticking point is going to be the small amount > of crypto stuff that websockets require. Not impossible maybe but difficult.
Yeah Chris, this mostly RFC-compliant websocket-server patch (that I outrageously announced on this list in january 2014) has all the required crypto stuff you talk about (made stricly of vanilla objects) : SHA-1 hashing + Base64 encoding... and how could it be otherwise ?! Billy brought its existence to your attention, so why keep using this conditional tense ? (or is this matter only up to you, New-York New-York?? haha). Since its release, many people found it on Sourceforge after typing "pd websocket" on google and the like, and used the original patch without problem (only recently asking for help with deken). So not impossible maybe but difficult to understand you didn't try to check this stuff...
And to answer to Bill now : except the mandatory [tcpserver] external, the core server subpatch is full vanilla (including crypto), as clearly mentioned next to it in the patch. Only the demo and specific examples used a couple of additionnal externals, mostly for pd messages<->ascii codes conversion (at that time the 'fromsymbol' options of the [list] object were new in vanilla but not yet in latest Pd-extended, which was the target release).
Sure, it's far from perfect, some part could be better, it's heavyweight, cpu intensive, and totally over the top if you just need to send and receive a dozen of little text messages every second. But, even if it won't scale well as message length and the number of clients grows, it has been thoroughly constructed and tested to handle the best as it can multiple concurrent connections/disconnections from all flavors of browsers, and to sustain up to 24 clients (a limit of implementation that can be easily enhanced, or even removed with mrpeach) and hundreds of kilobytes/seconds of total throughput with iemnet external (though lag, freeze or disconnections will occur more frequently when pushing it to the limits).
On Tue, Nov 22, 2016 at 12:29 AM, Billy Stiltner <billy.stiltner at gmail.com> wrote: > this is insane lol > you have the webpage in pd send the webpage to the browser before the > client(in the webpage) is connected to the > server. > just exactly how does that work? This is insanely working like it should do : https://en.wikipedia.org/wiki/WebSocket#Protocol_handshake
> and of course point the webbrowser to the port the server was connected to > instead of the one > shown in the yellow canvas instructions its not 9998 but the other one Hum..? There is one and only one tcp port in use (see previous answer)
> anyways, the tof library > and zexy library things , couldnt they now be replaced with vanilla > objects like > list to/from symbol? Yes they can, and to make things easier, I made just that with the new quasi-vanilla version (needs only to add mrpeach via the Help->Find externals menu) now available at the same place : https://sourceforge.net/projects/websocketserverinapatch/
It seems you were looking not only for "incoming text as pd messages" conversion, but also with "semicolon-style-send" support (which couldn't work with the funny but ugly trick of netsend/netreceive used locally only to parse numbers in symbols as proper floats, like the world's worst web server with a fancy name does : so much for your other questions left unanswered..). Maybe you were too shy to ask in your hearty emails, anyway I've added just that in the vanilla "text2pdmessage" subpatch especially for you.
> looks like lots of things could be simplified as well as Some of it could be simplified by dropping extended features like transparent support for both iemnet and mrpeach [tcpserver] externals and the convoluted workarounds addressed to some of their respective bugs in Pd-Extended, like those occuring when stressed or with keeped-alive connections (by the way, this was explained in detail in the info subpatches and comments).
> use of the vanilla netrecieve It can be done with some trivial additions to x_net.c that would bring the missing 'per-socket' operations to [netreceive] with a couple of additional commands + an optional third outlet, similarly to the 'net' externals. I made and tried a 40 lines diff-patch (that doesn't disrupt normal behaviour) and preliminary tests showed good performance and stability with this network intensive patch.