On Sun, 2009-03-01 at 12:56 -0500, Martin Peach wrote:
Roman Haefeli wrote:
On Tue, 2009-02-24 at 21:15 +0000, Martin Peach wrote:
Roman Haefeli wrote:
--- Martin Peach martin.peach@sympatico.ca schrieb am Di, 24.2.2009:
Roman Haefeli wrote:
>> On Mon, 2009-02-23 at 21:03 +0000, Martin
Peach wrote: Yes, I agree. I think a status outlet on the [tcpserver] could be extended later to have more messages. Some of the stuff that gets printed to the Pd window could go there and then it could be handled by the patch instead of the 'operator'. I don't want to keep adding more outlets, so it would output lists with a selector, like [comport].
i totally agree, that instead of adding more outlets it would be better to provide additional information on the same outlet with appropriate selector.
OK it's done for now, in svn. Each time something is sent, you get a "sent" message from the status outlet that gives the number of bytes that were actually sent and the client number. Also a [client( message with no data lists the connections using a "client" selector. The send function doesn't wait any more. If the number of bytes sent is zero, you have to try again. It all needs to be tested...
thank you for implementing those changes.
i finally had a chance (and time) to have a closer look and it turned out, that the additional information is actually no gain and this still doesn't allow to programm a non-blocking server. it seems, that the 'sent' message is output, when something was _added_ to the 'send' buffer. actually, we would need this message to appear when something was _removed_ from the buffer, which is when a message actually was sent.
Yes, because the actual buffer is hidden from the user. You should get a 'sent 0' message when it would block though, I don't know why you don't.
with the current implementation, the buffer still overruns without having the chance to know this beforehand. whenever i send a message to client, i get _immediately_ a 'sent 1 7' message, which i use to trigger the next message, etc. so buffer keeps filling and filling. when the buffer is full, [tcpserver] blocks pd. so, currently the situation is not different from the one before i have started this thread.
It's not supposed to do that. It should return 'sent 0' when it can't take any more, never block. Are you sending to the same client or many different ones? Can you post a test patch that will reproduce the bug? Something like this should stop when the buffer is full:
[bang][r stop] | | [until] | [send 1 7 7 7 7 7 7 7( | [tcpserver] | | | | | [route sent] | [select 0] | [s stop]
ah, now i see your example, i understand how the additional information is supposed to be used. however, i never see a 'sent 0' message. even after pluging the cable back again, so that the buffer is flushed, there is no 'sent 0' message, but only lots of 'sent 1 7' messages. this means, that this example patch didn't work for me. pd was blocked after 5700 or so 8-byte messages.
this is with a build from yesterday, so i will check out the todays build as well. you'll hear again from me soon. ;-)
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de