Hi Martin, IOhannes et al.
Martin, you asked me when I last tested mrpeach's [tcpserver] when I was mentioning the blocking issue. I did another test today with two computers connected over Ethernet. When plugging out the chord, I can simulate a client disappearing without the server noticing and thus filling the socket buffer on the server side. The behavior of [tcpserver] indeed changed since last time I tried. The test setup consisted of a server and a client on Computer A and a client on computer B. Client A sent messages that were broadcasted to both clients by the server. When plugging out the cable, client A (which is running on the same box as the server) did first still receive the messages. After a while, the server started printing lots of errors:
error: tcpserver_broadcast: couldn't create broadcast thread (11)
From then also client A didn't receive any messages anymore, although
the client was still sending messages to the server. After I plugged client B back in, it received all the messages sent by client A from the moment I unplugged the cable until the server started printing errors. However, all the subsequent messages (the ones, that triggered the errors) got lost.
The advantage of this behaviour is that the clients don't get blocked because the server is blocked. But this also means, that when the server is blocked, data is lost. Really problematic is the fact, that from the patch there is no way to detect such a data loss (or is there?). The old implementation (used still by [maxlib/netserver] and also [netsend]) blocks, but never loses any data. Though I think the new non-blocking behaviour is good, there should be a mechanism to know what got lost, so that a patch can handle such a situation and make sure to resend the data.
iemnet's [tcpserver] is again different, in that it buffers huge amounts of data without ever blocking. In my tests I wasn't able neither to block a client nor the server, nor to lose any data. Even if I let the client A sent a ton of data while client B was unplugged, after plugging client B back in, it received all the data that was sent in the meanwhile without dropping one single message.
@ IOhannes Though I like this 'stable'/reliable behaviour of iemnet's [tcpserver], I wonder what happens, if it keeps sending data to the unreachable client. Will it just go on and buffer everything until the whole RAM of the computer is consumed? If so, wouldn't it be more wise to just disconnect that client at some point in order to avoid the box running out of memory?
Roman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/09/2010 10:28 PM, Roman Haefeli wrote:
@ IOhannes Though I like this 'stable'/reliable behaviour of iemnet's [tcpserver], I wonder what happens, if it keeps sending data to the unreachable client. Will it just go on and buffer everything until the whole RAM of the computer is consumed? If so, wouldn't it be more wise to just disconnect that client at some point in order to avoid the box running out of memory?
you can query the fillstate of the buffer from within the patch and act upon that: if you prefer to disconnect after 300MB (because of the 2.5GB memory you have, 2GB are only swap), or if you rather go and crash or whatever...it's up to you.
fgmsadr IOhannes
On Dec 10, 2010, at 5:12 AM, IOhannes m zmölnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/09/2010 10:28 PM, Roman Haefeli wrote:
@ IOhannes Though I like this 'stable'/reliable behaviour of iemnet's [tcpserver], I wonder what happens, if it keeps sending data to the unreachable client. Will it just go on and buffer everything until the whole RAM of the computer is consumed? If so, wouldn't it be more wise to just disconnect that client at some point in order to avoid the box running out of memory?
you can query the fillstate of the buffer from within the patch and act upon that: if you prefer to disconnect after 300MB (because of the 2.5GB memory you have, 2GB are only swap), or if you rather go and crash or whatever...it's up to you.
A 300 MB network buffer! That sounds scary.
.hc
----------------------------------------------------------------------------
"A cellphone to me is just an opportunity to be irritated wherever you are." - Linus Torvalds
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/10/2010 04:54 PM, Hans-Christoph Steiner wrote:
A 300 MB network buffer! That sounds scary.
i thought i made it quite clear that it is up to the user what they want.
i find it far more scary to tell people what the might want (e.g. network buffers that are 1MB big, because some upstream author thought that i might get scared if it was any bigger.
fgmadr IOhannes
On Fri, 2010-12-10 at 10:54 -0500, Hans-Christoph Steiner wrote:
On Dec 10, 2010, at 5:12 AM, IOhannes m zmölnig wrote:
On 12/09/2010 10:28 PM, Roman Haefeli wrote:
@ IOhannes Though I like this 'stable'/reliable behaviour of iemnet's [tcpserver], I wonder what happens, if it keeps sending data to the unreachable client. Will it just go on and buffer everything until the whole RAM of the computer is consumed? If so, wouldn't it be more wise to just disconnect that client at some point in order to avoid the box running out of memory?
you can query the fillstate of the buffer from within the patch and act upon that: if you prefer to disconnect after 300MB (because of the 2.5GB memory you have, 2GB are only swap), or if you rather go and crash or whatever...it's up to you.
Great! That's even better than to disconnect clients at some arbitrary buffer size.
A 300 MB network buffer! That sounds scary.
It's not really a network buffer. If I understand correctly, it's the RAM used by the Pd process that grows, when this buffer is filled. I guess, there is nothing to be really scared about.
Anyway, there is no 'real' alternative to buffering data. When a certain client is not totally responsive, you either have to make the server blocking ([netsend]/[maxlib/netserver]), or you decide to discard data that cannot be delivered ([mrpeach/tcpserver]), or you buffer the data ([iemnet/tcpserver]). The last option is definitely the best, in my opinion.
Doing "networking with Pd" is special in that you use a real-time oriented framework (Pd) together with a 'time-agnostic' one. TCP only cares about _what_ is delivered, but not _when_. Accordingly, special measures are necessary to join both worlds in a reliable way.
Roman
On Dec 13, 2010, at 10:19 AM, Roman Haefeli wrote:
On Fri, 2010-12-10 at 10:54 -0500, Hans-Christoph Steiner wrote:
On Dec 10, 2010, at 5:12 AM, IOhannes m zmölnig wrote:
On 12/09/2010 10:28 PM, Roman Haefeli wrote:
@ IOhannes Though I like this 'stable'/reliable behaviour of iemnet's [tcpserver], I wonder what happens, if it keeps sending data to the unreachable client. Will it just go on and buffer everything until the whole RAM of the computer is consumed? If so, wouldn't it be more wise to just disconnect that client at some point in order to avoid the box running out of memory?
you can query the fillstate of the buffer from within the patch and act upon that: if you prefer to disconnect after 300MB (because of the 2.5GB memory you have, 2GB are only swap), or if you rather go and crash or whatever...it's up to you.
Great! That's even better than to disconnect clients at some arbitrary buffer size.
A 300 MB network buffer! That sounds scary.
It's not really a network buffer. If I understand correctly, it's the RAM used by the Pd process that grows, when this buffer is filled. I guess, there is nothing to be really scared about.
Anyway, there is no 'real' alternative to buffering data. When a certain client is not totally responsive, you either have to make the server blocking ([netsend]/[maxlib/netserver]), or you decide to discard data that cannot be delivered ([mrpeach/tcpserver]), or you buffer the data ([iemnet/tcpserver]). The last option is definitely the best, in my opinion.
Doing "networking with Pd" is special in that you use a real-time oriented framework (Pd) together with a 'time-agnostic' one. TCP only cares about _what_ is delivered, but not _when_. Accordingly, special measures are necessary to join both worlds in a reliable way.
Roman
I've never heard of an app do so much network buffering. At some point, that data needs to be processed, not just buffered. If you end up having a giant buffer, chances are there is a problem that needs to be dealt with. Might as well deal with it after a couple of megs are filled rather than just some
From what I've seen, most network buffering is done with a ring buffer, so a fixed size. That's my two bits...
.hc
----------------------------------------------------------------------------
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
On 2010-12-13 17:43, Hans-Christoph Steiner wrote:
From what I've seen, most network buffering is done with a ring buffer, so a fixed size. That's my two bits...
<flames> so what exactly are you trying to tell us?
one of the reasons for me to change my entire system and to switch to Pd was "choice": to make computers do what i prefer rather than what 'they' think i ought to prefer. even if i choose to prefer what has been chosen for me anyhow. </flames>
mfgdf IOhannes
On Dec 13, 2010, at 11:49 AM, IOhannes m zmoelnig wrote:
On 2010-12-13 17:43, Hans-Christoph Steiner wrote:
From what I've seen, most network buffering is done with a ring buffer, so a fixed size. That's my two bits...
<flames> so what exactly are you trying to tell us?
one of the reasons for me to change my entire system and to switch to Pd was "choice": to make computers do what i prefer rather than what 'they' think i ought to prefer. even if i choose to prefer what has been chosen for me anyhow.
</flames>
Just a comment on the topic of networking in Pd. I'm not threatening to change your code or make you stop. I'd really like to see robust networking in Pd, so I was trying to relay my experience.
.hc
----------------------------------------------------------------------------
Programs should be written for people to read, and only incidentally for machines to execute. - from Structure and Interpretation of Computer Programs
On Mon, 2010-12-13 at 11:43 -0500, Hans-Christoph Steiner wrote:
On Dec 13, 2010, at 10:19 AM, Roman Haefeli wrote:
On Fri, 2010-12-10 at 10:54 -0500, Hans-Christoph Steiner wrote:
On Dec 10, 2010, at 5:12 AM, IOhannes m zmölnig wrote:
On 12/09/2010 10:28 PM, Roman Haefeli wrote:
@ IOhannes Though I like this 'stable'/reliable behaviour of iemnet's [tcpserver], I wonder what happens, if it keeps sending data to the unreachable client. Will it just go on and buffer everything until the whole RAM of the computer is consumed? If so, wouldn't it be more wise to just disconnect that client at some point in order to avoid the box running out of memory?
you can query the fillstate of the buffer from within the patch and act upon that: if you prefer to disconnect after 300MB (because of the 2.5GB memory you have, 2GB are only swap), or if you rather go and crash or whatever...it's up to you.
Great! That's even better than to disconnect clients at some arbitrary buffer size.
A 300 MB network buffer! That sounds scary.
It's not really a network buffer. If I understand correctly, it's the RAM used by the Pd process that grows, when this buffer is filled. I guess, there is nothing to be really scared about.
Anyway, there is no 'real' alternative to buffering data. When a certain client is not totally responsive, you either have to make the server blocking ([netsend]/[maxlib/netserver]), or you decide to discard data that cannot be delivered ([mrpeach/tcpserver]), or you buffer the data ([iemnet/tcpserver]). The last option is definitely the best, in my opinion.
Doing "networking with Pd" is special in that you use a real-time oriented framework (Pd) together with a 'time-agnostic' one. TCP only cares about _what_ is delivered, but not _when_. Accordingly, special measures are necessary to join both worlds in a reliable way.
Roman
I've never heard of an app do so much network buffering.
Probably they don't because other apps are not Pd? (No sarcasm intended, I really think that many others apps are hardly comparable with Pd)
At some point, that data needs to be processed, not just buffered.
Actually, I was trying to explain exactly that in my previous post. In Pd, you only can do process data 'now', not 'somewhere within the next two hours'. So, either the sending side needs to buffer or it'll be blocked.
If you end up having a giant buffer, chances are there is a problem that needs to be dealt with.
The problem is that Pd is 'real-time'? I'm not sure if I understand where you're heading to.
Might as well deal with it after a couple of megs are filled rather than just some
The thing is, that it is perfectly possible to drop a client after buffering only a few kilobytes. There _might_ be situations where one prefers to buffer more. I wouldn't say that this is problematic by design. It really depends on the situation.
I'm sorry for constantly using netpd as an example, but part of it is sending dumps of all settings of all instruments to a freshly connected client. Obviously, I want neither the clients nor the server to be blocked at any time. Also, I don't want to drop any data. What could be implemented, though, would be to send only small chunks of data upon request. This would create huge programming overhead. It is _much_ easier and more transparent to buffer the data until everything is transmitted. As a patch programmer, I am still able to decide if there is a problem or not. Let's say if the buffer doesn't get smaller after 1 minute (arbitrary example), the server decides that this client is 'not responsive enough' and disconnects it. However, the most important thing - in my eyes - is that you have the freedom to design your networking Pd patch the way you prefer.
From what I've seen, most network buffering is done with a ring buffer, so a fixed size. That's my two bits...
I'm not knowledgeable enough to comment on the lack of a ring buffer. I assume it would be more efficient than a dynamically growing buffer? In this case the importance and necessity of a dynamic buffer probably outweighs the advantages of a fixed size ring buffer?
In my humble opinion, the approach used by iemnet's classes is the most suitable and most flexible I can think of and is inevitable for what I consider 'more elaborate' networking in Pd.
Roman
On 13/12/10 10:19 AM, Roman Haefeli wrote:
On Fri, 2010-12-10 at 10:54 -0500, Hans-Christoph Steiner wrote:
On Dec 10, 2010, at 5:12 AM, IOhannes m zmölnig wrote:
On 12/09/2010 10:28 PM, Roman Haefeli wrote:
@ IOhannes Though I like this 'stable'/reliable behaviour of iemnet's [tcpserver], I wonder what happens, if it keeps sending data to the unreachable client. Will it just go on and buffer everything until the whole RAM of the computer is consumed? If so, wouldn't it be more wise to just disconnect that client at some point in order to avoid the box running out of memory?
you can query the fillstate of the buffer from within the patch and act upon that: if you prefer to disconnect after 300MB (because of the 2.5GB memory you have, 2GB are only swap), or if you rather go and crash or whatever...it's up to you.
Great! That's even better than to disconnect clients at some arbitrary buffer size.
What? It's better to crash the server than to disconnect an unresponsive client? And if the server itself loses its connection it will buffer 300MB for each client and then crash?
Martin
On Mon, 2010-12-13 at 14:42 -0500, Martin wrote:
On 13/12/10 10:19 AM, Roman Haefeli wrote:
On Fri, 2010-12-10 at 10:54 -0500, Hans-Christoph Steiner wrote:
On Dec 10, 2010, at 5:12 AM, IOhannes m zmölnig wrote:
On 12/09/2010 10:28 PM, Roman Haefeli wrote:
@ IOhannes Though I like this 'stable'/reliable behaviour of iemnet's [tcpserver], I wonder what happens, if it keeps sending data to the unreachable client. Will it just go on and buffer everything until the whole RAM of the computer is consumed? If so, wouldn't it be more wise to just disconnect that client at some point in order to avoid the box running out of memory?
you can query the fillstate of the buffer from within the patch and act upon that: if you prefer to disconnect after 300MB (because of the 2.5GB memory you have, 2GB are only swap), or if you rather go and crash or whatever...it's up to you.
Great! That's even better than to disconnect clients at some arbitrary buffer size.
What? It's better to crash the server than to disconnect an unresponsive client?
Why crashing the server? I don't get the alarmism. If a patch needs to allocate 300 MB of RAM for storing sound files for fast access, that's a sensible reason to do so. Not less sensible is it to allocate 300 MB for buffering data to be transmitted over a network when necessary. Ok, 300 MB seems a lot (nowadays, at least), but that's some made up value. No need to stick with that. It's the responsibility of the patch programmer to ensure, that the required amount of memory is available, anyway. Not less so when doing GridFlow and storing huge grids, for instance.
If a networking patch programmer thinks it's stupid to buffer any data, they can decide to throw messages away instead of buffering them. [iemnet/tcpserver] gives that freedom. So what is your point?
And if the server itself loses its connection it will buffer 300MB for each client and then crash?
It will crash, if it runs out of memory (as any other Pd patch will as well). To stick with the somewhat arbitrary 300 MB example: What I was excited about is the ability to let the patch disconnect clients based on some values like (as one of many examples) buffer size. The example application would read: "If the buffer of a certain socket exceeds 300 MB, the according client will be disconnected by the server". Again, nobody said that one must use 300 MB as a threshold.
Roman
On 2010-12-13 23:15, Roman Haefeli wrote:
On Mon, 2010-12-13 at 14:42 -0500, Martin wrote:
What? It's better to crash the server than to disconnect an unresponsive client?
Why crashing the server? I don't get the alarmism. If a patch needs to
i think martin commented on my "if you rather go and crash or whatever...it's up to you."
and yes, i do think that if i as a patcher decide that it is the proper response to an unresponsive client to fill up the buffer until the server crashes, than i should be able to do this.
fgmasdr IOhannes
On Tue, 2010-12-14 at 08:52 +0100, IOhannes m zmoelnig wrote:
On 2010-12-13 23:15, Roman Haefeli wrote:
On Mon, 2010-12-13 at 14:42 -0500, Martin wrote:
What? It's better to crash the server than to disconnect an unresponsive client?
Why crashing the server? I don't get the alarmism. If a patch needs to
i think martin commented on my "if you rather go and crash or whatever...it's up to you."
and yes, i do think that if i as a patcher decide that it is the proper response to an unresponsive client to fill up the buffer until the server crashes, than i should be able to do this.
It seems that I sidetracked this conversation with my comment that was meant more as a "hmm, this might end up being problematic because its unusual" than arguing against the approach.
"Whatever works" is the key, IMHO.
.hc
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Martin -
Roman Haefeli