On Thu, 2009-04-30 at 10:17 -0400, Martin Peach wrote:
Roman Haefeli wrote:
i ve been testing the new netpd-server based on the new [tcpserver]/[tcsocketserver FUDI] now for a while and definitely could solve some problems, but some new ones were introduced.
i found, that the most recent version of [tcpserver] peforms quite bad cpu-wise. this has some side-effects. in netpd, when a certain number of users are logged in (let's say 16), it can happen, that the traffic of those clients makes the netpd-server use more than the available cpu-time. i made some tests and checked, if all messages come through and if messages delivered by the server are still intact. under normal circumstances, there is no problem at all. but under heavy load, when the pd process is demanding more than available cpu time, some messages are corrupted or lost completely; in the worst case the pd process segfaults, at the moment of a client connecting or disconnecting. i guess, this is due to some buffer under- or overrun between pd and the tcp stack, but i don't really know.
Hi Roman, Did you try using the new [timeout( message? The latest version of tcpserver defaults to a 1ms timeout, so if you have a bunch if disconnected clients, Pd will hang for 1ms each, which will quickly add up to more than the audio block time and then Pd will start thrashing and eventually die or become comatose, as it were.
no, i haven't tried this parameter yet. but i sure will do and report back, when i can tell more about how it behaves.
i haven't fully understood, what it does and what it can be used for. could you elaborate that a bit more? yet it sounds a bit strange to me, that i need to tweak a networking object with a time value for correct operation.
I think you need to experiment with different values for the timeout.
ok
Set it to zero and it should give the same results as the previous version;
you, mean, [tcpserver] will hang pd, when the buffer of a certain socket is full? or do you mean the version, that cut off some parts of messages under certain circumstances?
maybe try something around 100 instead of the default 1000 (it's in microseconds). The other way to fix this in the tcpserver source is to make a new thread for each client, but I'm afraid that will just open another can of worms/zombies.
i hardly know anything about threading, but i guess that is what other servers do (e.g apache). also didn't i see a way around creating dynamically an instance of the protocol handling abstraction for each socket, which is, i guess, something similar to threading in the pd world (not technically, but conceptually).
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de