-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2013-07-01 16:40, Iain Mott wrote:
Thanks very much IOhannes!
The mrpeach version was being loaded by default. When I use iemnet/tcpclient it doesn't crash. That's great.
it is, though i'm sometimes under the impression that mrpeach is a bit more stable than iemnet (rather than the other way around)
There's a difference however in the way mrpeach/tcpclient and iemnet/tcpclient sends received data to its output.
Messages from SSR received by mrpeach/tcpclient are sent to its output as a list (if that's the right word), for example as:
[...]
This is easily converted to a readable XML string with "string2any 0 0" to get:
<update><source id='1' level='-98.8531'/><source id='2' level='-100.177'/><source id='3' level='-100.556'/><source id='4' level='-98.3239'/></update>
iemnet/tcpclient on the other hand sends individual numbers to its output as a stream rather than a list.
[...]
....... etc.
And there are various messages of various lengths. I guess if I use iemnet/tcpclient I'll need to find a different way of parsing these numbers.... Not my strong point with Pd!
well the point is, that TCP/IP as an underlying protocol doesn't know anything about packets - it is stream-based, like a serial connection. if you are relying on the packets coming out of the [tcpclient] object as strings of the "correct" length, then your code is broken. you *must* have a way to determine the end of an atomic junk of data without relying on the list length. [iemnet/tcpclient] makes this obvious from the beginning, as it will never lure you into security of "correct length" lists (though there is a hidden flag that gives you the same behaviour as [mrpeach/tcpclient]). outputting the bytes one-by-one should actually make it easier to re-packetize the data.
e.g. your example string looks like '0' was a delimiting character (at least it appears at the end of the [mrpeach/tcpclient] example output). if this is indeed the case, you only have to [list append] the incoming bytes until you encounter "0", and then flush the buffer to the output - this way your packages will always be of the correct length.
I'll try the backtrace and other things you suggest and report back on mrpeach/tcpclient in another email.
it could well be, that it only does not crash with [iemnet/tcpclient] because you haven't parsed the output yet...
fgmads IOhannes