headers
Ivica Ico Bukvic | 1 May 2010 04:35
Picon
Favicon

mrpeach/tcpserver question

Martin,

I am looking into further improving tcpserver/tcpclient as we've encountered a number of issues while
using it with L2Ork. I am aware that we are currently using somewhat older version (0.42.5) plus the
patches I forwarded to you so please take this into account when reading the following observations.

There are 3 issues I can think of off top of my head:

1) when closing the patch with clients connected I get stuck port on a regular basis even though as far as I
could see in your source you've specified the flag that should allow for it to be freed near
instantaneously provided it is stuck in TIME_WAIT mode, namely:

933:	if (setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, 0, 0) < 0)
		post("setsockopt failed\n");

On Ubuntu 9.10 one has to wait for 60 seconds (default system setting) for the port to be freed. I've tried
customizing port timeout system-wide but that had no effect which appears to be Ubuntu issue. Still, I am
trying to figure out why the external is not closing the port cleanly. The end-result is that I effectively
have to wait up to 60 seconds between different pieces in order to be able to spawn a new conductor instance
(basically a focal intercommunication patch that deals with time-sensitive control data). Following
link suggests that perhaps the socket is stuck in a different mode upon close which makes the aforesaid
code irrelevant, thus suggesting that destructor may not be doing things quite right:
http://www.unixguide.net/network/socketfaq/4.5.shtml

2) when using broadcast option, it *consistently* causes audio xruns even though your iteration appears
to be heavily threaded. This has been such a large problem I had to design a coll-based iteration that keeps
count of active connections and their associated sockets and then using a metro dispatching messages to
individual clients at 5ms intervals by prefixing them with appropriate socket number until coll list is
exhausted. This is a terrible solution if one wishes to keep network jitter to a minimum between clients
(actually it is a terrible solution no matter what) as in this case in a 16-member ensemble, last member can
(Continue reading)

Permalink | Reply | 18 comments |
headers
Martin Peach | 1 May 2010 08:25
Picon
Favicon

Re: mrpeach/tcpserver question

Ivica Ico Bukvic wrote:
> Martin,
> 
> I am looking into further improving tcpserver/tcpclient as we've encountered a number of issues while
using it with L2Ork. I am aware that we are currently using somewhat older version (0.42.5) plus the
patches I forwarded to you so please take this into account when reading the following observations.
> 
> There are 3 issues I can think of off top of my head:
> 
> 1) when closing the patch with clients connected I get stuck port on a regular basis even though as far as I
could see in your source you've specified the flag that should allow for it to be freed near
instantaneously provided it is stuck in TIME_WAIT mode, namely:
> 
> 933:	if (setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, 0, 0) < 0)
> 		post("setsockopt failed\n");
> 
> On Ubuntu 9.10 one has to wait for 60 seconds (default system setting) for the port to be freed. I've tried
customizing port timeout system-wide but that had no effect which appears to be Ubuntu issue. Still, I am
trying to figure out why the external is not closing the port cleanly. The end-result is that I effectively
have to wait up to 60 seconds between different pieces in order to be able to spawn a new conductor instance
(basically a focal intercommunication patch that deals with time-sensitive control data). Following
link suggests that perhaps the socket is stuck in a different mode upon close which makes the aforesaid
code irrelevant, thus suggesting that destructor may not be doing things quite right:
> http://www.unixguide.net/network/socketfaq/4.5.shtml
> 

OK, thanks for finding that. I fixed it in svn, the way it is written 
above will not set SO_REUSEADDR because the parameter is false (0). Also 
it was #ifdeffed out except for IRIX. You should try an autobuild from 
tomorrow.
(Continue reading)

Permalink | Reply | 17 comments |
headers
Ivica Ico Bukvic | 1 May 2010 16:07
Picon
Favicon

Re: mrpeach/tcpserver question

> OK, thanks for finding that. I fixed it in svn, the way it is written
> above will not set SO_REUSEADDR because the parameter is false (0).
> Also
> it was #ifdeffed out except for IRIX. You should try an autobuild from
> tomorrow.

I'll definitely try it out but I am not convinced this is the problem as my port timeout adjustments
system-side had no effect suggesting that the port was stuck in a different mode than TIME_WAIT. Could it
be something wrong with the destructor?

> Yes, that's because in tcp broadcast it sends individual packets to each
> client, which can eat up time. I suggest using udp for data and tcp for
> control, as udp broadcast will send one packet to everyone on the
> subnet.

I understand that but we cannot use UDP as that one at times does not go through when there is a lot of traffic
(and we do use UDP for non-critical monitoring in addition to TCP). Last thing I want to have happen is
someone missing a critical cue due to dropped UDP packet (which in our case happens a lot--before we
switched to TCP I had to press button for the same cue 3-4 times before it was actually received by everyone).

Couldn't the broadcast command spawn a separate thread that then services all clients to avoid xruns?

> Not sure which version you have, but try it now:
> http://pure-data.svn.sourceforge.net/viewvc/pure-
> data/trunk/externals/mrpeach/net/tcpserver.c?view=log

Will do.

Many thanks for your help!
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ivica Ico Bukvic | 1 May 2010 16:55
Picon
Favicon

Re: mrpeach/tcpserver question

Martin,

Just tried the latest version and the problem with stuck port persists,
suggesting that either Ubuntu is doing something funny or that the
destructor is to blame.

A simple test to perform is to use attached test patch:

1) Connect the client
2) Close the patch without explicitly disconnecting the client
3) Reopen the patch and the tcpserver will fail to be created until the
timeout has taken place (on my machine 60 seconds)

Console output in this case is:

tcpserver listening on port 9999
tcpclient 2010 Martin Peach-style
tcpclient: connecting socket 8 to port 9999
tcpserver: accepted connection from 127.0.0.1 on socket 9
tcp_server_free...
...tcp_server_free
tcpclient_free...
tcpclient: disconnected
...tcpclient_free

However, if one explicitly disconnects before closing the patch, that
works just fine:

tcpserver listening on port 9999
tcpclient 2010 Martin Peach-style
(Continue reading)

Permalink | Reply | 14 comments |
headers
IOhannes m zmölnig | 1 May 2010 18:13
Picon

Re: mrpeach/tcpserver question


Ivica Ico Bukvic wrote:
> Martin,
> 
> Just tried the latest version and the problem with stuck port persists,
> suggesting that either Ubuntu is doing something funny or that the
> destructor is to blame.
> 

if you quit Pd, the destructors are not properly called for externals.
this is a rather serious issue reported on the sf-tracker soome years(?)
ago, but a fix never made it into Pd proper.

fgmasr
IOhannes
Permalink | Reply | 0 comments |
headers
Ivica Ico Bukvic | 1 May 2010 18:18
Picon
Favicon

Re: mrpeach/tcpserver question

> Ivica Ico Bukvic wrote:
> > Martin,
> >
> > Just tried the latest version and the problem with stuck port persists,
> > suggesting that either Ubuntu is doing something funny or that the
> > destructor is to blame.
> >
> 
> if you quit Pd, the destructors are not properly called for externals.
> this is a rather serious issue reported on the sf-tracker soome years(?)
> ago, but a fix never made it into Pd proper.

I am not quitting Pd but only closing the patch (not sure if that is the same thing). If so, is there fix so we
could at least commit it on our end?

Best wishes,

Ico
Permalink | Reply | 0 comments |
headers
Ivica Ico Bukvic | 1 May 2010 18:20
Picon
Favicon

Re: mrpeach/tcpserver question

> if you quit Pd, the destructors are not properly called for externals.
> this is a rather serious issue reported on the sf-tracker soome years(?)
> ago, but a fix never made it into Pd proper.

Also, in this case I don't think this is the problem as the verbose output shows that the free function was
called properly on both client and server, it is just that the server in its current state is apparently
unable to free the port if it still has clients connected to it.

Ico
Permalink | Reply | 0 comments |
headers
Martin Peach | 1 May 2010 18:31
Picon
Favicon

Re: mrpeach/tcpserver question

Ivica Ico Bukvic wrote:
> Martin,
> 
> Just tried the latest version and the problem with stuck port persists,
> suggesting that either Ubuntu is doing something funny or that the
> destructor is to blame.
> 
> A simple test to perform is to use attached test patch:
> 
> 1) Connect the client
> 2) Close the patch without explicitly disconnecting the client
> 3) Reopen the patch and the tcpserver will fail to be created until the
> timeout has taken place (on my machine 60 seconds)
> 

Hmmm, I just tried this on WinXP and it works fine (Pd version 
0.42.5-extended-20100411 but with the new tcpserver).
I can even open multiple copies of the patch without errors or failure 
to create.
I'll check later on a debian machine.

Martin
Permalink | Reply | 12 comments |
headers
Martin Peach | 1 May 2010 18:37
Picon
Favicon

Re: mrpeach/tcpserver question

Ivica Ico Bukvic wrote:
> 
> Couldn't the broadcast command spawn a separate thread that then services all clients to avoid xruns?

It might be better just to have it send the same buffer instead of 
repeatedly parsing the same input for each send (unless it's the thread 
creation itself that causes glitches). I'll look into it.

Martin
Permalink | Reply | 0 comments |
headers
SourceForge.net | 2 May 2010 11:11
Picon
Favicon

[ pure-data-Bugs-2995427 ] context menu offset

Bugs item #2995427, was opened at 2010-05-02 11:11
Message generated for change (Tracker Item Submitted) made by denis97531
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2995427&group_id=55736

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: D.P. (denis97531)
Assigned to: Nobody/Anonymous (nobody)
Summary: context menu offset

Initial Comment:
Hello 
when you move objects outside the visible window, on the upper side or the left side (for example when you
move a group of things to make room fo new objects), the display is re-adapted so that the object being too
far up or left are displayed again. This is fine but in this situation, the context menu (with
'properties', 'open', 'help') gets an offset, so when you click on an object to open it or get help, the
context menu is displayed far off the object, up or left, depending how you moved the objects before. 
It is possible to repair this offset by moving the whole patch down or right. But would it be possible to
simply avoid this offset in any case?
Thanks to all for this great software.

----------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |

Gmane