Justin Glenn Smith escribió:

never mind, I was confused there, a normal socket does allow both send and receive.

For PD to have two-way sockets, and have them be really useful, we would have to have dynamically created connections, and this kind of thing is a little trickier in PD than it is in a textual programming language.

I'm not sure I understand. Connection are already dynamically created: [netsend] connects to a server by sending it a "connect" message.

I don't dubt it is complicated to implement the sort of communication PD does, but given what is already implemented, I don't see the "extra" complication of implementing a scenario similar to the one I described.

And from the standpoint of the user (or patcher), I think it would be pretty flexible and quite simple, i.e. you wouldn't need to worry about the tricky socket complications much more than you need do now.....

All the semantics are already there: [netsend] behaves as a client and already have the connect and disconnect functionalities; it would only need an outlet from which it would output messages it receives from the server (once it has connected). [netreceive] behaves as a server: it would only need an inlet and a "send" method that would behave exactly as the one of [netsend] (but would send to the client, provided.........

Oh! Here's the part I had overlooked! The fact that the current [netreceive] (which is a server) only receives, means that having more than one clients connected to it isn't an "issue" because you don't have to address them. Being able to send through a server socket would imply either: A) somewhat identifying and addressing the connected clients when sending to them (e.g. a "send" message should have an argument somehow identifying the client to send to), or B) just sending to all the clients currently connected.

B would mean reduced functionality compared to a "full featured" server socket, but already something more than the current only-receive server (netreceive). In the case of only one connected client (a pretty common case I guess) it would provide easy bidirectional communication.

A serious (A) solution would be indeed complicated, but not impossible to devise. For example, the [would-be-server]'s outlet that currently only outputs the number of connected clients, could output a message every time an incoming connection is established, and such a message would include the IP address of the client, the TCP port (not of much use presumably), and a unique ID, unique to the _connection_ (call it session if you want). Then the "send" message for the [would-be-server] object would be "send _id_ ..." (where ... is the message to be sent).

With this information, you would be able to recognize the client by its IP address if you need to.....

Just an idea.

m.