hi martin
i reckon, that you're working on tcpserver code these days, at least when ever i update mrpeach from svn, the tcpserver.c file is updated. so please tell me, if it makes sense at all to currently report bugs.
after having set the buffersize using the 'clientbuf' messages, message to the client, for which the buffersize was set, are truncated. while sending 30 byte messages, only 15 bytes are sent, respectively 15 bytes are received on the client side.
please check the attached bug illustration patch
roman
Well I'm trying to get rid of the bugs in it... I don't get that on WinXP though (Pd 0.41.4-extended). I set the buffer to 12 and still received 30 bytes. On Debian with Pd 0.41.4-extended I get two separate messages (each longer than 12) but still all the data arrives.
Martin
From: reduzierer@yahoo.de To: pd-dev@iem.at Date: Mon, 6 Apr 2009 17:38:20 +0200 Subject: [PD-dev] [tcpserver]: new 'clientbuf' method seems to be buggy
hi martin
i reckon, that you're working on tcpserver code these days, at least when ever i update mrpeach from svn, the tcpserver.c file is updated. so please tell me, if it makes sense at all to currently report bugs.
after having set the buffersize using the 'clientbuf' messages, message to the client, for which the buffersize was set, are truncated. while sending 30 byte messages, only 15 bytes are sent, respectively 15 bytes are received on the client side.
please check the attached bug illustration patch
roman
On Mon, 2009-04-06 at 20:33 +0000, martin.peach@sympatico.ca wrote:
Well I'm trying to get rid of the bugs in it... I don't get that on WinXP though (Pd 0.41.4-extended). I set the buffer to 12 and still received 30 bytes. On Debian with Pd 0.41.4-extended I get two separate messages (each longer than 12) but still all the data arrives.
here, on my ubuntu 8.04 box, the patch i sent behaves this way:
- after connecting, the 30 byte message from server to client comes through, but is splitted into two messages of 15 bytes, sometimes 1 and 29 bytes.
- after sending 'clientbuf 1 1024' to [tcpserver], only the 15 bytes come through, and sometimes only the very first byte.
tell me, if there is anything i could help you with.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Spoke too soon. On Debian setting the buffer to any size always returns me 2048, so that's no good. On WinXP some values (1,2) do what you said. Others (10,12) don't. I'm not sure what to do about that. It seems to be the OS.
Martin
From: martin.peach@sympatico.ca To: reduzierer@yahoo.de; pd-dev@iem.at Date: Mon, 6 Apr 2009 20:33:15 +0000 Subject: Re: [PD-dev] [tcpserver]: new 'clientbuf' method seems to be buggy
Well I'm trying to get rid of the bugs in it... I don't get that on WinXP though (Pd 0.41.4-extended). I set the buffer to 12 and still received 30 bytes. On Debian with Pd 0.41.4-extended I get two separate messages (each longer than 12) but still all the data arrives.
Martin
From: reduzierer@yahoo.de To: pd-dev@iem.at Date: Mon, 6 Apr 2009 17:38:20 +0200 Subject: [PD-dev] [tcpserver]: new 'clientbuf' method seems to be buggy
hi martin
i reckon, that you're working on tcpserver code these days, at least when ever i update mrpeach from svn, the tcpserver.c file is updated. so please tell me, if it makes sense at all to currently report bugs.
after having set the buffersize using the 'clientbuf' messages, message to the client, for which the buffersize was set, are truncated. while sending 30 byte messages, only 15 bytes are sent, respectively 15 bytes are received on the client side.
please check the attached bug illustration patch
roman
On Mon, 2009-04-06 at 21:26 +0000, martin.peach@sympatico.ca wrote:
Spoke too soon. On Debian setting the buffer to any size always returns me 2048, so that's no good. On WinXP some values (1,2) do what you said. Others (10,12) don't. I'm not sure what to do about that. It seems to be the OS.
i would say, that the ability to set the buffer to any arbitrary size is not critical. though, it is really critical, if messages are not sent completely.
i cannot think of situations, where one is really dependent on a small buffersize. whatever works with small buffersize, should work as well with bigger buffersizes, shouldn't it? however, the reverse of that is not true. so if you are saying, that every buffersize _above_ a certain value works fine, then i am really fine with it. the reason, why i was using small (200 or 1024) buffersizes was wanting to debug the netpd-server.
or are you saying that some buffersizes work, others don't, and that it is completely unrelated to whether they are big or small?
roman
________________________________________________________________________
From: martin.peach@sympatico.ca To: reduzierer@yahoo.de; pd-dev@iem.at Date: Mon, 6 Apr 2009 20:33:15 +0000 Subject: Re: [PD-dev] [tcpserver]: new 'clientbuf' method seems to be buggy
Well I'm trying to get rid of the bugs in it... I don't get that on WinXP though (Pd 0.41.4-extended). I set the buffer to 12 and still received 30 bytes. On Debian with Pd 0.41.4-extended I get two separate messages (each longer than 12) but still all the data arrives.
Martin
From: reduzierer@yahoo.de To: pd-dev@iem.at Date: Mon, 6 Apr 2009 17:38:20 +0200 Subject: [PD-dev] [tcpserver]: new 'clientbuf' method seems to be
buggy
hi martin
i reckon, that you're working on tcpserver code these days, at least when ever i update mrpeach from svn, the tcpserver.c file is
updated. so
please tell me, if it makes sense at all to currently report bugs.
after having set the buffersize using the 'clientbuf' messages,
message
to the client, for which the buffersize was set, are truncated.
while
sending 30 byte messages, only 15 bytes are sent, respectively 15
bytes
are received on the client side.
please check the attached bug illustration patch
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On Mon, 2009-04-06 at 21:26 +0000, martin.peach@sympatico.ca wrote:
Spoke too soon. On Debian setting the buffer to any size always returns me 2048, so that's no good. On WinXP some values (1,2) do what you said. Others (10,12) don't. I'm not sure what to do about that. It seems to be the OS.
here, what [tcpserver] reporst as the used buffersize, is always twice the number i send. for numbers below 1024, 2048 is reported. for numbers higher than 131071, always 262142 is reported.
i found some *magic* borders, probably the numbers tell you something. i don't know what to do with them. those borders are between 3014 and 3015, and the other one between 6029 and 6030
when setting the buffersize to: < 3015, only the first 15 bytes come through of every message sent < 6030, only the first 16 bytes come through of every message sent
for setting buffersize to >= 6030, messages to a length up to 64 bytes are sent correctly. i haven't tested bigger messages.
don't know, probably those numbers can help you track down the problem. it's funny, that none of them are a power of two.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli wrote:
On Mon, 2009-04-06 at 21:26 +0000, martin.peach@sympatico.ca wrote:
Spoke too soon. On Debian setting the buffer to any size always returns me 2048, so that's no good. On WinXP some values (1,2) do what you said. Others (10,12) don't. I'm not sure what to do about that. It seems to be the OS.
here, what [tcpserver] reporst as the used buffersize, is always twice the number i send. for numbers below 1024, 2048 is reported. for numbers higher than 131071, always 262142 is reported.
It's completely up to the operating system to manage the buffers the way it chooses. If you ask for a buffer of a certain size you can get anything above that size as a result. So Linux appears to never go below 2048 while Windows gives you whatever you ask for.
Anyway, today I changed [tcpserver] and [tcpclient] in svn to use a default 1ms timeout in the select call before sending each byte. This seems to give the buffer time to clear before attempting to send the next byte. You can change the timeout in microseconds with the [timeout( message if you want to tweak it. A value of zero works most of the time but the problem of dropped data seems to disappear if you use about 1ms. The timeout should normally not delay Pd because it only comes into effect when the buffer is not emptying fast enough.
Martin
On Wed, 2009-04-08 at 18:49 -0400, Martin Peach wrote:
Roman Haefeli wrote:
On Mon, 2009-04-06 at 21:26 +0000, martin.peach@sympatico.ca wrote:
Spoke too soon. On Debian setting the buffer to any size always returns me 2048, so that's no good. On WinXP some values (1,2) do what you said. Others (10,12) don't. I'm not sure what to do about that. It seems to be the OS.
here, what [tcpserver] reporst as the used buffersize, is always twice the number i send. for numbers below 1024, 2048 is reported. for numbers higher than 131071, always 262142 is reported.
It's completely up to the operating system to manage the buffers the way it chooses. If you ask for a buffer of a certain size you can get anything above that size as a result. So Linux appears to never go below 2048 while Windows gives you whatever you ask for.
Anyway, today I changed [tcpserver] and [tcpclient] in svn to use a default 1ms timeout in the select call before sending each byte. This seems to give the buffer time to clear before attempting to send the next byte. You can change the timeout in microseconds with the [timeout( message if you want to tweak it. A value of zero works most of the time but the problem of dropped data seems to disappear if you use about 1ms. The timeout should normally not delay Pd because it only comes into effect when the buffer is not emptying fast enough.
thanks for the update. i'll be happy to test.
roman
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
-
Martin Peach -
martin.peach＠sympatico.ca
-
Roman Haefeli