[PD-dev] mrpeach/tcpserver question

[Ivica Ico Bukvic]

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 be receiving message as late as 16*5 or 90ms (plus obviously inherent network latency). Anything less than 5ms between sends yields unstable results.

3) at times tcpserver misreports number of connections and tends to crash, almost as if it fails to properly detect disconnection.

Any ideas what might be the problem and whether any of these problems have been addressed in the latest version?

Best wishes,

Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Assistant Co-Director, CCTAD
CHCI, CS, and Art (by courtesy)
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-6139
(540) 231-5034 (fax)
ico at vt.edu
http://www.music.vt.edu/faculty/bukvic/