On Sun, 2009-03-01 at 22:53 -0500, Martin Peach wrote:
Roman Haefeli wrote:
On Sun, 2009-03-01 at 19:30 -0500, Martin Peach wrote:
I think the blocking happens because the connection is gone, not because of the buffer overflowing.
i am not sure, if understand what you mean here. what i experience: when i overrun the buffer (by plugging out the ethernet cable to the client), the pd process of [tcpserver] is completely blocked after having sent $BUFFERSIZE bytes. it stays blocked, until i plug in the cable back again. the whole content of the buffer is sent after some seconds and the server pd instance responds again. this means, that even if the connection is not completely lost, a blocking of pd could occur.
You can send until the buffer fills up, even if it isn't emptying. I think it blocks because it only checks for at least one empty space in the buffer but then sends more than that.
exactly. if the next message is bigger than the left free space in the buffer, pd is blocked. i guess, we mean the same thing.
if the connection to the client is permanently lost, then there is no way to make pd responding again, after a buffer overrun occured.
If the connection is present the buffer will be emptying as fast as the network can drain it, so just pacing the writes should work. Trying to write an infinite amount instantly won't.
i can't follow here as well. it's not about trying to send an infinite amount of data in zero time. it's about not knowing the current connection condition, and because of that risking a drop-out. since the connection condition changes all the time, you cannot implement a self-adapting system in pd without knowing the internal buffer status (empty or not). so even if you send data with a fixed rate, it still could happen, that you trigger the buffer overrun.
Well I guess empty and almost full are the same as long as we stick to single bytes.
ah, yes..
So I made [tcpserver] send the messages one byte at a time. This latest version should not block, since it adds only one element to the buffer for each select call that says the buffer is still writeable.
can you tell me something about how to use it correctly? i just compiled the newest version and still could prevent it from blocking pd. before the blocking happens, i do _not_ get any message from the new outlet from [tcpserver], such as 'sent 0'. so what happens is still, that i send messages to it until it blocks. is it different on windows? do you mind sending me a windows binary, if it is? is there anything i can do in terms of testing on linux?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de