On Apr 28, 2006, at 7:59 PM, Martin Peach wrote:
Mathieu Bouchard wrote:
On Wed, 26 Apr 2006, B. Bogart wrote:
Actually I think we could do: net/tcpsend net/tcpreceive net/udpsend net/udpreceive
bidi connections are nice, so let's merge the send/receive parts
together: net/tcpsocket net/udpsocketBut we don't have midisocket, just midiin and midiout, and it's
easier to patch that way. For instance I'm using OSC to talk to microcontrollers on one port
but they reply on another. To me it makes more sense to have
separate send and receive objectsand each would be both able to run in server mode (waiting for
connections) and client mode (issuing connections), and if not,
call the server mode objects like: net/tcpserver net/udpservertcpreceive accepts multiple incoming connections (maximum is set by
a #define in the code but it could be a creation argument if
needed), and updreceive accepts any messages sent to its port
number. Both also output the ip address of the source of each
incoming message.
I have to say that I really think that tcp and udp objects should be
bidirectional. TCP and UDP sockets are, so the objects should
represent that. I've done quite a bit of network programming with Pd
and I never use [netsend]/[netreceive]. I always use [netserver]/
[netclient] because of the bidirectional connection and the client
management of the [netserver].
I think the "server" aspect could be a separate object. I think the
socket objects should represent just the sockets, and how the sockets
work.
.hc
"Information wants to be free." -Stewart Brand