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

Tue Nov 29 20:25:23 CET 2016

>> has all the required crypto stuff you talk about (made stricly of
vanilla objects)

whoa... i didn't realize this could all be done via vanilla and when i
checked your code this past summer did not see this portion so thanks for
pointing it out!

in the end i ended up using python to do crypto stuff but seeing this makes
me wonder what more can be done direct in pd. would it be nice to have some
kind of "crypto" lib? maybe some of this code could be separated out into
abstractions? how to do sha-256, hmac, etc?

i am thinking out loud here...

thanks!
m

On Mon, Nov 28, 2016 at 2:47 AM, s p <sebpiq at gmail.com> wrote:

> Sorry for intruding the discussion ... there's also this solution I've
> been implementing and using with Pd for live performances :
>
> https://github.com/sebpiq/rhizome
>
> It's node.js based, so it should be very performant.
>
> ------ end of advertisment :)  ------
>
> On Mon, Nov 28, 2016 at 4:04 AM Nicolas Lhommet <nlhommet at gmail.com>
> wrote:
>
>> 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üß !
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
>> listinfo/pd-list
>>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>

-- 
____________________
m.e.grimm, m.f.a, ed.m.
syracuse u., tc3
megrimm.net
____________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20161129/c84af12e/attachment-0001.html>