[PD] [PD-announce] All-in-one 'websocket server + cross-browser multiplayer/multitouch demo' patch for Pd-extended

[Nicolas Lhommet]

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 iemnet tcp server or the onefrom mr 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.

Still, besides simple bi-directionnal http mechanisms now possible for a
couple of years in pd-vanilla, a better and more pragmatic approach for
websockets, like for any kind of (widespread enough) intensive low level
stuff,  would be to quickly build an external on top of an existing, well
tested library, and that's what Rafael Vega did and announced here in 2013
: https://github.com/dancing-bone-machine/dancing-bone-machine
/tree/master/library/dancing-bone-machine/pd/externals/src/websocket_server

"I want to be a part of it... and find I'm A number one, King of the hill,
Top of the List..Head of the heap" ahaha!! Tschüß !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20161128/31693384/attachment.html>