I have made progress but it's still not working :(
The heart of the issue seems to be the subtlety in bridging UDP network traffic, which is by definition unidirectional, stateless and connectionless, over a TCP channel, which is the opposite: bidirectional, stateful and connection-based. What we want to achieve with socat is firstly to establish a single, permanent, long-living, bidirectional TCP tunnel using port 34831. Then, we want to leverage the udp-recvfrom / udp-sendto bits to capture the UDP datagrams in either direction and transmit them to the other side through the tunnel. I don't think this has been achieved with my versions of socat, OS, etc. and the options used. Prior, I reported that the replies from LMS to the Player were not going back through the tunnel. I found the reason for that was, due to the unusually lengthy network latency between my LMS and Player, the local socat was -closing- the TCP socket before the response arrived back from the remote side. Connection longevity seems to be controlled by the "-t" parameter (lowercase) and by default it's 0.5 seconds. By adding a "-t3600" to my local socat, I finally was able to see the replies from LMS getting back to the Player. If the network latency between a Player and remote LMS was under 500ms this issue may not occur. So with that in place, I progressed a bit. Now when I start the Player, it does its discovery and discovers 2 servers, 127.0.0.1 and MacMini2. The latter is the name of my LMS and was found due to the discovery process now working. Attempting to connect to these took me to the Username/Password dialog, again which was very promising. However, after entering the credentials I am again stuck with the Player reporting it is not able to connect to the server (either 127.0.0.1 or MacMini2). What I see a lot of is that every time the Player emits a UDP packet, a new TCP connection request is logged by ssh. This results in hundreds of open TCP connections, which is not a good thing. When I kill off the socats ssh reports closing all these connections, but it shouldn't be like this. We should only be creating 1 long lived TCP connection, keeping it alive so that it may transfer UDP datagrams whenever they are emitted. What I do see is continuous chatter on the UDP channel, the same request being emitted over and over again by SqueezePlay. And responses from LMS arriving much later. Probably, this is due to a retry mechanism built into SqueezePlay. With UDP, there is no built-in retry mechanism like TCP, delivery of each datagram is "best effort" only, and all retry logic must be done in the app itself. Because UDP is a fast and light connectionless protocol, designed to work best over local area networks, it's likely we are seeing a timeout issue where if the Player does not get a response to its first UDP message in a certain very short period it retries and sends another. This cascades - it may send 5 or 6 requests out before the first reply comes back over ssh/socat. This is what the logging data suggests is going on in my case. As to why, after the discovery handshake succeeds, the Player still cannot connect to LMS is a mystery. socat is quite a complex utility and there may be further options available to fine-tune how the UDP/TCP bridging works to solve these issues. For now, I'm going to have to leave it. Thanks. ------------------------------------------------------------------------ nico's Profile: http://forums.slimdevices.com/member.php?userid=672 View this thread: http://forums.slimdevices.com/showthread.php?t=108734 _______________________________________________ Squeezecenter mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/squeezecenter
