<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 04/20/2015 04:05 AM, IOhannes m
zmoelnig wrote:<br>
</div>
<blockquote cite="mid:5534B354.9070609@iem.at" type="cite">
<pre wrap="">On 2015-04-19 22:45, Jonathan Wilkes via Pd-list wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 04/19/2015 03:46 PM, IOhannes m zmölnig wrote:
</pre>
<blockquote type="cite">
<pre wrap="">since TCP/IP is totally packet agnostic, thou shalt not rely on it's
packetizing capabilities.
if your receiver emits packets the same as you sent them, then you were
merely lucky.
</pre>
</blockquote>
<pre wrap="">
Thanks. There's a string-decoder lib that puts a buffer's extra "tail"
bytes
in a separate bin so they can be prepended to the next buffer. That
sounds like
the way to go.
</pre>
</blockquote>
<pre wrap="">
any packetizing token ('"tail" bytes') needs to be excluded from or
within from the actual payload.</pre>
</blockquote>
<br>
Well, there are two things:<br>
1) partial FUDI message at the end of a buffer<br>
2) bytes of a UTF-8 character split across two different buffers<br>
<br>
The algorithm I have been using can silently fail on #2,<br>
but the solution to that is trivial. Given that solution, I<br>
can guarantee #1 is handled correctly.<br>
<br>
I'm just curious why I'm unable to ever trigger a run-time<br>
error for #2.<br>
<br>
<blockquote cite="mid:5534B354.9070609@iem.at" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">
I wonder if localhost is doing optimizations that make the problem
unlikely to happen.
</pre>
</blockquote>
<pre wrap="">
do not trust it.</pre>
</blockquote>
<br>
I don't. I'm just making sure I understand how a vital part of the<br>
gui message passing system works, by trying to break it based<br>
on what I've learned from reading the spec on the underlying
protocol.<br>
<br>
<blockquote cite="mid:5534B354.9070609@iem.at" type="cite">
<pre wrap="">
much broken multithreaded code used to work fine on single-core
machines, because the single-threaded architecture made some problems
unlikely to happen. and then we got multiple cores...
(admittedly, this story is entirely made up by me; but there is no
reason why it should not not true)
</pre>
<blockquote type="cite">
<pre wrap="">
Right, but one can easily lose data before that part of the algorithm
happens. Node's Buffer API makes this extremely easy to do. The
string-decoder lib makes it easy to remedy, though.
</pre>
</blockquote>
<pre wrap="">
if you "can easily lose data" over your TCP/IP connection then something
is seriously wrong with your setup.</pre>
</blockquote>
<br>
I am not losing data over the TCP/IP connection. I am potentially
losing data<br>
before tokenizing the FUDI messages. That's because I was using a
"toString"<br>
method which silently gets corrupted when bytes of a multi-byte
character<br>
straddle two incoming buffers of data.<br>
<br>
Anyway it's trivial to fix-- again, I was just curious why I cannot
trigger<br>
a corruption at all, even when flooding the socket with messages
that have<br>
a large percentage of multi-byte characters.<br>
<br>
<blockquote cite="mid:5534B354.9070609@iem.at" type="cite">
<pre wrap="">
(but anyhow, i don't know the actual problem you are working on, and i
assumed that it is about your gui-rewrite. i'm nitpicky to make you
avoid putting too much (== any) code depending on node.js features into
the Pd-core side. but you are most likely aware of that anyhow)</pre>
</blockquote>
<br>
It's difficult to imagine how I could hard code a node.js<br>
dependency into it.<br>
<br>
As far as Javascript...<br>
I do have a handful of wrappers around sys_vgui in s_inter.c.<br>
Those wrappers are tailored to being eval'd in Javascript.<br>
This is because it's easy and easily changed (should a better<br>
approach implement itself).<br>
<br>
The code to replace sys_vgui calls in g_*.c is quite similar to<br>
pd_vmess. There is one set of convenience functions I used<br>
for garray, scalars, and iemgui props which rely on an ability<br>
to send arrays of data to the gui. While I think it'd be great<br>
to do symmetric FUDI, there's a reason why arrays exist<br>
and my sanity is one of them.<br>
<br>
But if there are better approaches, it shouldn't take too long<br>
for interested parties to revise the wrappers and demo the<br>
benefits.<br>
<br>
-Jonathan<br>
<br>
<blockquote cite="mid:5534B354.9070609@iem.at" type="cite">
<pre wrap="">
fgmasdr
IOhannes
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a class="moz-txt-link-freetext" href="http://lists.puredata.info/listinfo/pd-list">http://lists.puredata.info/listinfo/pd-list</a>
</pre>
</blockquote>
<br>
</body>
</html>