<div dir="ltr"><div class="gmail_extra">Hi pd folks ! Billy <span id="m_-4176141756719308772:xe.1">Stiltner</span> kindly forwarded me its recent posts, so I briefly <span id="m_-4176141756719308772:xe.2">suscribe</span> to the list again only to reply to these questions regarding my old (and sole) publicly released pd tool.</div><div class="gmail_extra"><br></div><div class="gmail_extra">On Thu, Nov 18, 2016 at 16:16 PM, Chris McCormick <<span id="m_-4176141756719308772:xe.3">chris</span> at <a href="http://mccormick.cx" target="_blank"><span id="m_-4176141756719308772:xe.4">mccormick</span>.<span id="m_-4176141756719308772:xe.5">cx</span></a>> wrote:<br>> The reason I didn't implement a <span id="m_-4176141756719308772:xe.6">websocket</span> server is because I'd have to <br>> figure out how to do <span id="m_-4176141756719308772:xe.7">sha</span> hashing in pure-Pd and that is more effort <br>> than I can put in right now.<br>...<br>>> did you see the pd <span id="m_-4176141756719308772:xe.8">websocket</span> server?<br>>> it has some similar parts but looks way more complicated and is not<br>>> vanilla plus it uses <span id="m_-4176141756719308772:xe.9">iemnet</span> <span id="m_-4176141756719308772:xe.10">tcp</span> server or the <span id="m_-4176141756719308772:xe.11">onefrom</span> <span id="m_-4176141756719308772:xe.12">mr</span> peach, would be<br>>> nice<br>>> to reduce the number of connections and <span id="m_-4176141756719308772:xe.13">vanilarize</span> it just for a simple<br>>> <span id="m_-4176141756719308772:xe.14">fudi</span> thing<br>> <br>> Yeah it would be but the sticking point is going to be the small amount <br>> of <span id="m_-4176141756719308772:xe.15">crypto</span> stuff that <span id="m_-4176141756719308772:xe.16">websockets</span> require. Not impossible maybe but difficult.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Yeah Chris, this mostly RFC-compliant <span id="m_-4176141756719308772:xe.17">websocket</span>-server patch (that I outrageously announced on this list in <span id="m_-4176141756719308772:xe.18">january</span> 2014) has all the required <span id="m_-4176141756719308772:xe.19">crypto</span> stuff you talk about (made stricly of vanilla objects) : <span id="m_-4176141756719308772:xe.20">SHA</span>-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?? <span id="m_-4176141756719308772:xe.21">haha</span>). Since its release, many people found it on <span id="m_-4176141756719308772:xe.22">Sourceforge</span> after typing "pd <span id="m_-4176141756719308772:xe.23">websocket</span>" on google and the like, and used the original patch without problem (only recently asking for help with <span id="m_-4176141756719308772:xe.24">deken</span>). So not impossible maybe but difficult to understand you didn't try to check this stuff...</div><div class="gmail_extra"><br></div><div class="gmail_extra">And to answer to Bill now : except the mandatory [<span id="m_-4176141756719308772:xe.25">tcpserver</span>] external, the core server <span id="m_-4176141756719308772:xe.26">subpatch</span> is full vanilla (including <span id="m_-4176141756719308772:xe.27">crypto</span>), as clearly mentioned next to it in the patch. Only the demo and specific examples used a couple of <span id="m_-4176141756719308772:xe.29">additionnal</span> externals, mostly for pd messages<-><span id="m_-4176141756719308772:xe.30">ascii</span> 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).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Sure, it's far from perfect, some part could be better, it's heavyweight, <span id="m_-4176141756719308772:xe.31">cpu</span> 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 <span id="m_-4176141756719308772:xe.32">mrpeach</span>) and hundreds of kilobytes/seconds of total throughput with <span id="m_-4176141756719308772:xe.33">iemnet</span> external (though lag, freeze or disconnections will occur more frequently when pushing it to the limits). </div><div class="gmail_extra"><br></div><div class="gmail_extra">On Tue, Nov 22, 2016 at 12:29 AM, Billy <span id="m_-4176141756719308772:xe.34">Stiltner</span> <billy.<span id="m_-4176141756719308772:xe.35">stiltner</span> at <a href="http://gmail.com" target="_blank">gmail.com</a>> wrote:<br>> this is insane <span id="m_-4176141756719308772:xe.36">lol</span><br>> you have the <span id="m_-4176141756719308772:xe.37">webpage</span> in pd send the <span id="m_-4176141756719308772:xe.38">webpage</span> to the browser before the<br>> client(in the <span id="m_-4176141756719308772:xe.39">webpage</span>) is connected to the<br>> server.<br>> just exactly how does that work?<br>This is insanely working like it should do : <a href="https://en.wikipedia.org/wiki/WebSocket#Protocol_handshake" target="_blank">https://en.<span id="m_-4176141756719308772:xe.40">wikipedia</span>.org/wiki/<span id="m_-4176141756719308772:xe.41"><wbr>WebSocket</span>#Protocol_handshake</a></div><div class="gmail_extra"><br></div><div class="gmail_extra">> and of course point the <span id="m_-4176141756719308772:xe.42">webbrowser</span> to the port the server was connected to<br>> instead of the one<br>> shown in the yellow canvas instructions its not 9998 but the other one<br>Hum..? There is one and only one <span id="m_-4176141756719308772:xe.43">tcp</span> port in use (see previous answer)</div><div class="gmail_extra"><br></div><div class="gmail_extra">> anyways, the <span id="m_-4176141756719308772:xe.44">tof</span> library<br>> and <span id="m_-4176141756719308772:xe.45">zexy</span> library things , <span id="m_-4176141756719308772:xe.46">couldnt</span> they now be replaced with vanilla<br>> objects like<br>> list to/from symbol?<br>Yes they can, and to make things easier, I made just that with the new quasi-vanilla version (needs only to add <span id="m_-4176141756719308772:xe.47">mrpeach</span> via the Help->Find externals menu) now available at the same place :<br><a href="https://sourceforge.net/projects/websocketserverinapatch/" target="_blank">https://<span id="m_-4176141756719308772:xe.48">sourceforge</span>.net/projec<wbr>ts/<span id="m_-4176141756719308772:xe.49">websocketserverinapatch</span>/</a></div><div class="gmail_extra"><br></div><div class="gmail_extra">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 <span id="m_-4176141756719308772:xe.50">netsend</span>/<span id="m_-4176141756719308772:xe.51">netreceive</span> 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" <span id="m_-4176141756719308772:xe.52">subpatch</span> especially for you.</div><div class="gmail_extra"><br></div><div class="gmail_extra">> looks like  lots of things could be simplified as well as<br>Some of it could be simplified by dropping extended features like transparent support for both <span id="m_-4176141756719308772:xe.53">iemnet</span> and <span id="m_-4176141756719308772:xe.54">mrpeach</span> [<span id="m_-4176141756719308772:xe.55">tcpserver</span>] externals and the convoluted workarounds addressed to some of their respective bugs in Pd-Extended, like those <span id="m_-4176141756719308772:xe.56">occuring</span> when stressed or with <span id="m_-4176141756719308772:xe.57">keeped</span>-alive connections (by the way, this was explained in detail in the info <span id="m_-4176141756719308772:xe.58">subpatches</span> and comments).</div><div class="gmail_extra"><br></div><div class="gmail_extra">> use of the vanilla <span id="m_-4176141756719308772:xe.59">netrecieve</span><br>It can be done with some trivial additions to x_net.c that would bring the missing 'per-socket' operations to [<span id="m_-4176141756719308772:xe.60">netreceive</span>] 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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Still, besides simple bi-<span id="m_-4176141756719308772:xe.61">directionnal</span> http mechanisms now possible for a couple of years in pd-vanilla, a better and more pragmatic approach for <span id="m_-4176141756719308772:xe.62">websockets</span>, 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 : <a href="https://github.com/dancing-bone-machine/dancing-bone-machine/tree/master/library/dancing-bone-machine/pd/externals/src/websocket_server" target="_blank">https://<span id="m_-4176141756719308772:xe.63">github</span>.com/dancing-bon<wbr>e-machine/dancing-bone-machine<wbr>/tree/master/library/dancing-<wbr>bone-machine/pd/externals/<span id="m_-4176141756719308772:xe.64">src</span>/<span id="m_-4176141756719308772:xe.65"><wbr>websocket</span>_server</a></div><div class="gmail_extra"><br></div><div class="gmail_extra">"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" <span id="m_-4176141756719308772:xe.66">ahaha</span>!! <span id="m_-4176141756719308772:xe.67">Tschüß</span> !<br></div></div>