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.
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.
i don't know, how much control you have at c level over what is happening at tcp level. in order to solve the current issues at pd-level, information about either the current buffer size or amount of sent bytes (number of bytes removed from the buffer) would be required. i don't know how and if this is possible at all.
i would be interested to read about the c functions providing tcp capabilities. may i ask where you got your knowledge about those?
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de