hi,
i can't give any hints here but..
i just wanna thank you guys a lot that you're getting to solve this problem
with a lot of dirty hands while mine stays clean.
This problem brought us (in the past ;) ) a lot of interruption in exciting
netpd-jams.
all the best,
moritz
On Wed, Mar 4, 2009
Roman Haefeli wrote:
On Wed, 2009-03-04 at 08:08 +0900, PSPunch wrote:
The earlier sounds like to introduce massive overhead caused by TCP
headers, especially when we are speak of sending amounts of data that
may flood the socket's send buffer. In the later case, the OS may
indicate that
Roman Haefeli wrote:
On Wed, 2009-03-04 at 00:45 +0100, Roman Haefeli wrote:
how do i know, when the [tcpserver] socket is ready to transmit another
byte? do i have to nag it every ms with a message? if i go the
BYTE-AT-A-TIME route, the interval would even need to be slower, if
higher
On Wed, 2009-03-04 at 09:14 -0500, Martin Peach wrote:
martin, would you mind implementing similar changes to [tcpclient] as
well?
I'll do that today if I have time.
yo... no hurry.. but it seems you already did it. many thanks.
those changes to [tcpserver] and [tcpclient] enable
i really wonder, how other projects handle that. i mean, if several
people download a big file from apache, then a disappearing client
doesn't interfere with the other clients. i guess, in apache it is
solved by using threads. when using threads, one single thread doesn't
necessarily need to
PSPunch wrote:
From my understanding, the alternative to using multiple
threads/processes would be to set the socket to non-blocking and
implement a Pd object that buffers the messages requested to be sent.
Then attempts to retry sending what the OS once rejected should be made.
It seems
Hi Martin,
From my understanding, the alternative to using multiple
threads/processes would be to set the socket to non-blocking and
implement a Pd object that buffers the messages requested to be sent.
Then attempts to retry sending what the OS once rejected should be made.
It seems
On Mon, 2009-03-02 at 18:51 -0500, Martin Peach wrote:
Roman Haefeli wrote:
On Sun, 2009-03-01 at 22:53 -0500, Martin Peach wrote:
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
On Wed, 2009-03-04 at 00:45 +0100, Roman Haefeli wrote:
how do i know, when the [tcpserver] socket is ready to transmit another
byte? do i have to nag it every ms with a message? if i go the
BYTE-AT-A-TIME route, the interval would even need to be slower, if
higher troughput should be
On Wed, 2009-03-04 at 00:45 +0100, Roman Haefeli wrote:
how do i know, when the [tcpserver] socket is ready to transmit another
byte? do i have to nag it every ms with a message? if i go the
BYTE-AT-A-TIME route, the interval would even need to be slower
i either wanted to say 'lower' or
On Tue, 2009-03-03 at 18:44 +0900, PSPunch wrote:
i really wonder, how other projects handle that. i mean, if several
people download a big file from apache, then a disappearing client
doesn't interfere with the other clients. i guess, in apache it is
solved by using threads. when using
On Wed, 2009-03-04 at 08:08 +0900, PSPunch wrote:
The earlier sounds like to introduce massive overhead caused by TCP
headers, especially when we are speak of sending amounts of data that
may flood the socket's send buffer. In the later case, the OS may
indicate that bytes entered the
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
Roman Haefeli wrote:
On Sun, 2009-03-01 at 22:53 -0500, Martin Peach wrote:
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
On Tue, 2009-02-24 at 21:15 +, Martin Peach wrote:
Roman Haefeli wrote:
--- Martin Peach martin.pe...@sympatico.ca schrieb am Di, 24.2.2009:
Roman Haefeli wrote:
On Mon, 2009-02-23 at 21:03 +, Martin
Peach wrote:
Yes, I agree. I think a status outlet on the [tcpserver]
Roman Haefeli wrote:
On Tue, 2009-02-24 at 21:15 +, Martin Peach wrote:
Roman Haefeli wrote:
--- Martin Peach martin.pe...@sympatico.ca schrieb am Di, 24.2.2009:
Roman Haefeli wrote:
On Mon, 2009-02-23 at 21:03 +, Martin
Peach wrote:
Yes, I agree. I think a status outlet on the
Martin Peach wrote:
Roman Haefeli wrote:
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
On Sun, 2009-03-01 at 12:56 -0500, Martin Peach wrote:
Roman Haefeli wrote:
On Tue, 2009-02-24 at 21:15 +, Martin Peach wrote:
Roman Haefeli wrote:
--- Martin Peach martin.pe...@sympatico.ca schrieb am Di, 24.2.2009:
Roman Haefeli wrote:
On Mon, 2009-02-23 at 21:03 +, Martin
On Sun, 2009-03-01 at 14:01 -0500, Martin Peach wrote:
Martin Peach wrote:
Roman Haefeli wrote:
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
On Sun, 2009-03-01 at 17:01 -0500, Martin Peach wrote:
So I added a [clientbuf( message to [tcpserver] to get/set the size of
the send buffer. Apparently the actual buffer will be twice this size.
when i set the buffer to 10, i get a message:
tcpserver_buf_size: client 1 set to 2048
when no
Roman Haefeli wrote:
On Sun, 2009-03-01 at 17:01 -0500, Martin Peach wrote:
[snip]
Probably I need to set the sockets to nonblocking.
what does that mean: setting sockets to non-blocking? will this cause
the sockets to simply ommit data, that cannot be sent in time?
On Sun, 2009-03-01 at 19:30 -0500, Martin Peach wrote:
But if you know how much data you want to send you could set the buffer
to at least that size first.
yeah, this works for the very first time you send a chunk of data. the
next time, you don't know, if the buffer is already empty again
On Mon, 2009-03-02 at 00:02 +, Claude Heiland-Allen wrote:
Roman Haefeli wrote:
On Sun, 2009-03-01 at 17:01 -0500, Martin Peach wrote:
[snip]
Probably I need to set the sockets to nonblocking.
what does that mean: setting sockets to non-blocking? will this cause
the sockets to
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
Roman Haefeli wrote:
On Mon, 2009-02-23 at 19:05 -0500, Martin Peach wrote:
Roman Haefeli wrote:
On Mon, 2009-02-23 at 21:03 +, Martin Peach wrote:
OK I fixed it now in svn. It works on debian. The select() call was not
being done properly. Now I need to test it on Windows again.
hey,
--- Martin Peach martin.pe...@sympatico.ca schrieb am Di, 24.2.2009:
Roman Haefeli wrote:
On Mon, 2009-02-23 at 19:05 -0500, Martin Peach wrote:
Roman Haefeli wrote:
On Mon, 2009-02-23 at 21:03 +, Martin
Peach wrote:
OK I fixed it now in svn. It works on
debian. The select()
Roman Haefeli wrote:
--- Martin Peach martin.pe...@sympatico.ca schrieb am Di, 24.2.2009:
Roman Haefeli wrote:
On Mon, 2009-02-23 at 21:03 +, 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
On Sun, 2009-02-22 at 18:42 -0500, Martin Peach wrote:
Roman Haefeli wrote:
On Sun, 2009-02-22 at 17:30 -0500, Martin Peach wrote:
Maybe you could try it (I just uploaded it to the svn at
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mrpeach/net/)
and see
From: Roman Haefeli reduzie...@yahoo.de
Reply-To: reduzie...@yahoo.de
To: Martin Peach martin.pe...@sympatico.ca
CC: PD list pd-list@iem.at
Subject: Re: [PD] pd and tcp: what to do against crashes?
Date: Mon, 23 Feb 2009 19:50:44 +0100
On Sun, 2009-02-22 at 18:42 -0500, Martin Peach wrote
On Mon, 2009-02-23 at 19:10 +, Martin Peach wrote:
From: Roman Haefeli reduzie...@yahoo.de
Reply-To: reduzie...@yahoo.de
To: Martin Peach martin.pe...@sympatico.ca
CC: PD list pd-list@iem.at
Subject: Re: [PD] pd and tcp: what to do against crashes?
Date: Mon, 23 Feb 2009 19:50:44
On Mon, 2009-02-23 at 19:10 +, Martin Peach wrote:
From: Roman Haefeli reduzie...@yahoo.de
Reply-To: reduzie...@yahoo.de
To: Martin Peach martin.pe...@sympatico.ca
CC: PD list pd-list@iem.at
Subject: Re: [PD] pd and tcp: what to do against crashes?
Date: Mon, 23 Feb 2009 19:50:44
From: Roman Haefeli reduzie...@yahoo.de
Reply-To: reduzie...@yahoo.de
To: Martin Peach martin.pe...@sympatico.ca
CC: pd-list@iem.at
Subject: Re: [PD] pd and tcp: what to do against crashes?
Date: Mon, 23 Feb 2009 20:59:41 +0100
On Mon, 2009-02-23 at 19:10 +, Martin Peach wrote:
From
Roman Haefeli wrote:
with the newest [tcpserver] i cannot send messages to clients anymore.
i
tried both, 'send socketnumber' and 'client number'. whenever
[tcpserver] receives such a message, pd is blocked for about a second
and the i get in the console:
tcpserver_send_buf: client
On Mon, 2009-02-23 at 21:03 +, Martin Peach wrote:
Roman Haefeli wrote:
with the newest [tcpserver] i cannot send messages to clients anymore.
i
tried both, 'send socketnumber' and 'client number'. whenever
[tcpserver] receives such a message, pd is blocked for about a second
Roman Haefeli wrote:
On Mon, 2009-02-23 at 21:03 +, Martin Peach wrote:
OK I fixed it now in svn. It works on debian. The select() call was not
being done properly. Now I need to test it on Windows again.
hey, many thanks! it works. now i wonder, what happens, if the message
is
On Mon, 2009-02-23 at 19:05 -0500, Martin Peach wrote:
Roman Haefeli wrote:
On Mon, 2009-02-23 at 21:03 +, Martin Peach wrote:
OK I fixed it now in svn. It works on debian. The select() call was not
being done properly. Now I need to test it on Windows again.
hey, many thanks! it
On Sat, 2009-02-21 at 12:59 -0500, Martin Peach wrote:
Hi Roman,
I think it probably comes down to the code not checking for all possible
error conditions.
cool, if it would be as simple as that.
Under udp you can send as much as you like to
nonexistent receivers but tcp needs an active
Roman Haefeli wrote:
On Sat, 2009-02-21 at 12:59 -0500, Martin Peach wrote:
Hi Roman,
I think it probably comes down to the code not checking for all possible
error conditions.
cool, if it would be as simple as that.
Under udp you can send as much as you like to
nonexistent receivers
On Sun, 2009-02-22 at 15:17 -0500, Martin Peach wrote:
Roman Haefeli wrote:
On Sat, 2009-02-21 at 12:59 -0500, Martin Peach wrote:
Hi Roman,
I think it probably comes down to the code not checking for all possible
error conditions.
cool, if it would be as simple as that.
Under
I just tried with 2 machines having [tcpserver] (WinXP) repeatedly send
to [tcpclient] (Ubuntu) while I pulled out the cable from one machine.
The server keeps sending until it disconnects about a minute later with
message
tcpserver: not a valid socket number (-1)
The client however thinks it's
11584 tcpserver/linux
131760 tcpclient/OS X
On Sun, 2009-02-22 at 17:30 -0500, Martin Peach wrote:
I just tried with 2 machines having [tcpserver] (WinXP) repeatedly send
to [tcpclient] (Ubuntu) while I pulled out the cable from one machine.
The server keeps sending until it disconnects
On Sun, 2009-02-22 at 17:30 -0500, Martin Peach wrote:
Maybe you could try it (I just uploaded it to the svn at
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mrpeach/net/)
and see if anything changes.
now, i cannot compile it anymore, when i do:
cd
Roman Haefeli wrote:
On Sun, 2009-02-22 at 17:30 -0500, Martin Peach wrote:
Maybe you could try it (I just uploaded it to the svn at
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/mrpeach/net/)
and see if anything changes.
now, i cannot compile it anymore, when i
hi all
i've been working now quite some time with setups, where different
instances of pd spread over the world are connected with each other over
another instance of pd (i.e. serverpatch). i tried different classes for
establishing tcp connections between clients and servers, namely
Hi Roman,
I think it probably comes down to the code not checking for all possible
error conditions. Under udp you can send as much as you like to
nonexistent receivers but tcp needs an active connection.
Most likely the code is just assuming that everything is working properly.
It sounds as
45 matches
Mail list logo
