hi all, hi martin
as pointed out in a previous thread, it's tricky to use [tcp*] object classes for transporting packet oriented protocols, such as OSC or FUDI. when dealing with [tcpserver], the situation gets even more tricky. when several clients are connected to a [tcpserver] and they all send data in a packet oriented protocol simultaneously, the packets from several sockets might get mixed up on the server side, since tcp is not packet-aware and frames sent by clients might get splitted (or even concatenated). the only way i found to overcome that problem, was to make [tcpserver] protocol-aware, so that it keeps track of the several incoming streams and creates protocol-compliant packets out of them. on the other hand, i wanted a generic solution, that could be extended with support for more protocols than initally implemented. that is why i made:
[tcpsocketserver <protocol> <port>]
from what i understand, it works the same way, as other servers for a packet-oriented protocol work. whenever a new client connects, [tcpsocketserver] dynamically creates an instance of a socket handler, an abstraction, that is called [ŧcpsocket.PROTOCOLNAME]. all data received on that socket is sent to the appropriate handler. the handler contains the code, that forms proper packets from the incoming stream and sends the packets back to [tcpsocketserver]. no matter in what order and in what frame sizes the streams are received, [tcpsocketserver] only outputs valid, protocol-compliant packets.
yet, two protocols are supported: OSC and FUDI. support for the protocol FOO can be added by creating another socket handler, naming it tcpsocket.FOO.pd and putting in the code, that makes FOO-packets out of the incomding stream. then it can be called with [tcpsocketserver FOO 1234].
i hope this all makes sense to you. comments are welcome, of course. if you, martin, find it useful, i'd be glad, if this could make it into the mrpeach library.
my main purpose for doing this was to be able to transmit OSC packets in a multiclient<->server environment, which is finally working well since [tcpsocketserver].
http://www.romanhaefeli.net/software/pd/tcpsocketserver.tar.gz
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
This looks very cool, we need an easy to use OSC replacement for dumpOSC/sendOSC. One thing, I get this when I load them:
unpackOSCstream ... couldn't create unpackOSCstream ... couldn't create packOSCstream ... couldn't create packOSCstream ... couldn't create
I can't find those anywhere.
.hc
On Jan 11, 2009, at 8:40 PM, Roman Haefeli wrote:
hi all, hi martin
as pointed out in a previous thread, it's tricky to use [tcp*] object classes for transporting packet oriented protocols, such as OSC or FUDI. when dealing with [tcpserver], the situation gets even more tricky. when several clients are connected to a [tcpserver] and they all send data in a packet oriented protocol simultaneously, the packets from several sockets might get mixed up on the server side, since tcp is not packet-aware and frames sent by clients might get splitted (or even concatenated). the only way i found to overcome that problem, was to make [tcpserver] protocol-aware, so that it keeps track of the several incoming streams and creates protocol-compliant packets out of them. on the other hand, i wanted a generic solution, that could be extended with support for more protocols than initally implemented. that is why i made:
[tcpsocketserver <protocol> <port>]
from what i understand, it works the same way, as other servers for a packet-oriented protocol work. whenever a new client connects, [tcpsocketserver] dynamically creates an instance of a socket handler, an abstraction, that is called [ŧcpsocket.PROTOCOLNAME]. all data received on that socket is sent to the appropriate handler. the handler contains the code, that forms proper packets from the incoming stream and sends the packets back to [tcpsocketserver]. no matter in what order and in what frame sizes the streams are received, [tcpsocketserver] only outputs valid, protocol-compliant packets.
yet, two protocols are supported: OSC and FUDI. support for the protocol FOO can be added by creating another socket handler, naming it tcpsocket.FOO.pd and putting in the code, that makes FOO-packets out of the incomding stream. then it can be called with [tcpsocketserver FOO 1234].
i hope this all makes sense to you. comments are welcome, of course. if you, martin, find it useful, i'd be glad, if this could make it into the mrpeach library.
my main purpose for doing this was to be able to transmit OSC packets in a multiclient<->server environment, which is finally working well since [tcpsocketserver].
http://www.romanhaefeli.net/software/pd/tcpsocketserver.tar.gz
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http:// messenger.yahoo.de
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
Hans-Christoph Steiner wrote:
This looks very cool, we need an easy to use OSC replacement for dumpOSC/sendOSC. One thing, I get this when I load them:
unpackOSCstream ... couldn't create unpackOSCstream ... couldn't create packOSCstream ... couldn't create packOSCstream ... couldn't create
afaik, they are in mrpeach/osc (as has been discussed on some list: the problem with tcp/ip as a transport of OSC being a stream-based protocol rather than packet-based)
fgmadsr IOhannes
IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
This looks very cool, we need an easy to use OSC replacement for dumpOSC/sendOSC. One thing, I get this when I load them:
unpackOSCstream ... couldn't create unpackOSCstream ... couldn't create packOSCstream ... couldn't create packOSCstream ... couldn't create
afaik, they are in mrpeach/osc (as has been discussed on some list: the problem with tcp/ip as a transport of OSC being a stream-based protocol rather than packet-based)
They are there in svn at least. I just committed the tcpsocketserver abstractions in the same place. I haven't had time to test them though...
Martin
On Jan 13, 2009, at 9:06 AM, Martin Peach wrote:
IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
This looks very cool, we need an easy to use OSC replacement for dumpOSC/sendOSC. One thing, I get this when I load them:
unpackOSCstream ... couldn't create unpackOSCstream ... couldn't create packOSCstream ... couldn't create packOSCstream ... couldn't create
afaik, they are in mrpeach/osc (as has been discussed on some list: the problem with tcp/ip as a transport of OSC being a stream-based protocol rather than packet-based)
They are there in svn at least. I just committed the tcpsocketserver abstractions in the same place. I haven't had time to test them though...
Martin
Ah yeah, I see them in externals/mrpeach/osc, I was looking in 'net'.
.hc
----------------------------------------------------------------------------
All information should be free. - the hacker ethic
On Mon, 2009-01-12 at 15:26 -0500, Hans-Christoph Steiner wrote:
This looks very cool, we need an easy to use OSC replacement for dumpOSC/sendOSC. One thing, I get this when I load them:
i am afraid, that they do not make it easier for the user to use mrpeach/osc. at the least the goal was to make [tcpserver] work at all for OSC transportation. [tcpsocketserver] is supposed to be used the same way as one would use [tcpserver]. as IOhannes already mentioned, the problem is, that TCP is a stream-based protocol and packet-agnostic, whereas OSC is a packet based protocol and wants packets to be received exactly the same way as they were sent. [tcpserver] - since it talks plain TCP - cannot guarantee that.
we need an easy to use OSC replacement for dumpOSC/sendOSC.
do you mean, it would make sense to have something 'abstracted out', that does OSC un/packing and transport in a single class? i could try, if i get clear picture of how it should be done.
unpackOSCstream ... couldn't create unpackOSCstream ... couldn't create packOSCstream ... couldn't create packOSCstream ... couldn't create
I can't find those anywhere.
yo, as others already pointed out, those are part of svn in mrpeach.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Martin Peach -
Roman Haefeli