Roman Haefeli wrote:
On Mon, 2009-02-23 at 21:03 +0000, Martin Peach wrote:
OK I fixed it now in svn. It works on debian. The select() call was not being done properly. Now I need to test it on Windows again.
hey, many thanks! it works. now i wonder, what happens, if the message is triggered: 'tcpserver_send_buf: client 1 not writeable'. does that indicated, that the buffer is cleared? does it mean, that when this message appears, that at least one message didn't come through?
Right now it means that the message is dropped. I can't see a way of holding on to it that wouldn't end up crashing Pd eventually if you keep sending to an unconnected client.
somehow i need to design netpd in way, that as soon as one single message is lost, the connection should be shut down and established again, and the client should then again sync with other clients. otherwise very bad things could happen (patches are not transmitted completely and loading incomplete patches causes pd crashing).
Well the easiest thing would be to have [tcpserver] close the connection itself when that happens. The next best would be to have it output a message on a 'status' outlet that you could use to close the connection.
before the change i could be sure, that either all messages came through or the server crashed at some point, if messages could not be delivered. now, since the server doesn't crash anymore, i need to know, if messages were dropped. how can i know?
At the moment it prints to the Pd window, which isn't much use for control purposes. As I said, for me the easiest and most logical thing is to have the connection closed automatically, but then you have to keep track of the connection count to know whether it happened. What do you think?
Martin