Xbox Connections Not Closing

I am running Serviio 1.3.1 on a Debian server, and I've noticed that Xbox 360 Connections never close.
Connections to all my other media devices close as soon as they cease transmission. phone, tv, etc. work fine.
but connections to my Xbox never close. 20 hours after xbox has been turned off, all previously made connections are still ESTABLISHED
tcpdump shows no packets going to or from that address.
The connections close as soon as I restart, not Serviio, but the Java process it is running. I have latest JRE 7u45 x64

Any ideas why this might be?

Also, why does Serviio not use UDP? TCP seems unnecessary for the data stream.

Thanks for any insight.

[zip]

Usually it's the job of the renderer to close the socket. I will have a look.

TCP is the UPnP standard.

Any insights on this yet? I'm getting the same behavior on a Windows server. The zombie connections to my 360 persist until I bounce the Serviio process.

[zip]

can you post output of netstat showing this?

also, does this happen only after playing a video or also when just browsing?

Video? Heck, I'm just using it to stream music. (I like C418's work as much as the next guy, but Minecraft's tracklist is a bit too short for my tastes.) I use Serviio because my music library includes a bit of OGG and FLAC, so transcoding was on my short list of requirements.

I'm also not sure if simple browsing produces zombie connections. I'll check that specifically and post when I have a definite answer.

Anyway, here's the (truncated) output of "netstat -a", as I'm sure you don't need all 120+ irrelevant lines of output. 192.168.10.247 is the server. 192.168.10.240 is the 360, which has been shut off for over 15 hours at this point. Before printing each of these four "ESTABLISHED" lines, netstat pauses for about 10 seconds; there is no such pause related to any other line in the output.

I've also connected to Serviio using a simple Android UPnP client. That activity does not leave these zombie connections.

  Code:

Active Connections

  Proto  Local Address          Foreign Address        State
[...]
  TCP    192.168.10.247:8895    192.168.10.240:24922   ESTABLISHED
  TCP    192.168.10.247:8895    192.168.10.240:27085   ESTABLISHED
  TCP    192.168.10.247:8895    192.168.10.240:46703   ESTABLISHED
  TCP    192.168.10.247:8895    192.168.10.240:57989   ESTABLISHED
[...]

All right. After a bit more research, I'm now ... even more confused. The end result is still consistent, but what actually happens seems odd to this particular layman.

To answer the immediate question left hanging from last time: no, just browsing the music library does not in itself create a lingering connection. You know what does create the lingering zombie connection?

Shutting down the 360.

If the playlist goes through several very short tracks in rapid succession, there's a dynamic of connections established, used, and then left in TIME_WAIT state to be cleared out later. For instance, playing through a few tracks from "Music to Wear Pants To" (most tracks less than 30 seconds), then stopping the player, leaves these three connections cooling their heels:

  Code:

  TCP    192.168.10.247:8895    192.168.10.240:47192   TIME_WAIT
  TCP    192.168.10.247:8895    192.168.10.240:50638   TIME_WAIT
  TCP    192.168.10.247:8895    192.168.10.240:51228   TIME_WAIT

But then I shut down the 360, and all that's left on the server is this:

  Code:

  TCP    192.168.10.247:8895    192.168.10.240:46093   ESTABLISHED

Which, that foreign port wasn't even being used by any of the previous connections. I only thought to investigate this angle when I finished playing games for the night, shut down the game console, remembered I owed you a look at the connections, checked the starting state in netstat, and realized there was one more zombie connection when I hadn't even used the music player.

[zip]

might be useful to enable detailed logging, reproduce the hanging connection and try to search the source port number in the log to see if you can it and if you can what call was made from that port.

Good detective work

Okay, now we're getting somewhere. I kind of forgot your advice about looking for the port and instead concentrated on the timestamps, which ultimately lay out a pretty clear picture of what's going on. Here's the log fragment in question:

2013-12-12 23:51:19,715 DEBUG [DiscoverySSDPMessageListener] Received a valid NOTIFY (ssdp:byebye) message from Renderer 61406566-2205-2000-0000-0017fa290807 from address /192.168.10.240:65356
2013-12-12 23:51:19,715 DEBUG [RendererManager] Removing renderer 61406566-2205-2000-0000-0017fa290807 from list of active renderers
2013-12-12 23:51:36,126 DEBUG [DiscoverySSDPMessageListener] Received a valid NOTIFY (ssdp:alive) message from Renderer 61406566-2205-2000-0000-0017fa290807 from address /192.168.10.240:31921
2013-12-12 23:51:36,126 DEBUG [RendererManager] Adding renderer Renderer [uuid=61406566-2205-2000-0000-0017fa290807, ipAddress=192.168.10.240, name=Xbox 360, profileId=3, manuallyAdded=false, forcedProfile=false, enabled=true, accessGroupId=1] to list of active renderers
2013-12-12 23:51:36,329 DEBUG [DiscoverySSDPMessageListener] Received a valid M-SEARCH message for search target uuid:d30ed390-f67e-3260-b7c0-28d9aa66601d from address /192.168.10.240:5271s
2013-12-12 23:51:36,329 DEBUG [DiscoverySearchResponder] Sending 1 M-SEARCH response message(s) to /192.168.10.240:5271
2013-12-12 23:51:36,907 DEBUG [DiscoverySSDPMessageListener] Received a valid NOTIFY (ssdp:alive) message from Renderer 61406566-2205-2000-0000-0017fa290807 from address /192.168.10.240:31921
2013-12-12 23:51:37,324 DEBUG [DiscoverySSDPMessageListener] Received a valid M-SEARCH message for search target uuid:d30ed390-f67e-3260-b7c0-28d9aa66601d from address /192.168.10.240:5271s
2013-12-12 23:51:37,325 DEBUG [DiscoverySearchResponder] Sending 1 M-SEARCH response message(s) to /192.168.10.240:5271
2013-12-12 23:51:38,325 DEBUG [DiscoverySSDPMessageListener] Received a valid M-SEARCH message for search target uuid:d30ed390-f67e-3260-b7c0-28d9aa66601d from address /192.168.10.240:5271s
2013-12-12 23:51:38,326 DEBUG [DiscoverySearchResponder] Sending 1 M-SEARCH response message(s) to /192.168.10.240:5271
2013-12-12 23:51:39,364 DEBUG [ServiioHttpService] Incoming request from /192.168.10.240:64053: GET /deviceDescription/d30ed390-f67e-3260-b7c0-28d9aa66601d HTTP/1.1, headers = [User-Agent: Xbox/2.0.16547.0 UPnP/1.0 Xbox/2.0.16547.0,Connection: Keep-alive,Host: 192.168.10.247:8895]]
2013-12-12 23:51:39,364 DEBUG [RendererDAOImpl] Reading a Renderer with ip address 192.168.10.240
2013-12-12 23:51:39,364 DEBUG [DeviceDescriptionRequestHandler] DeviceDescription request received for device d30ed390-f67e-3260-b7c0-28d9aa66601d from 192.168.10.240 (headers = [User-Agent: Xbox/2.0.16547.0 UPnP/1.0 Xbox/2.0.16547.0,Connection: Keep-alive,Host: 192.168.10.247:8895])
2013-12-12 23:51:39,364 DEBUG [RendererDAOImpl] Reading a Renderer with ip address 192.168.10.240
2013-12-12 23:51:39,364 DEBUG [RendererManager] Looking for a renderer profile for Http headers: [User-Agent: Xbox/2.0.16547.0 UPnP/1.0 Xbox/2.0.16547.0,Connection: Keep-alive,Host: 192.168.10.247:8895]
2013-12-12 23:51:39,364 DEBUG [RendererDAOImpl] Reading a Renderer with ip address 192.168.10.240
2013-12-12 23:51:39,364 DEBUG [DeviceDescriptionRequestHandler] Sending DeviceDescription XML back using profile 'Xbox 360'

So, the sequence of events:

23:51:19 - I hit "Turn off" on the 360, which promptly sends the "byebye" signal to Serviio. Serviio dutifully removes it from the active list.
23:51:36 - However, it takes the 360 a little time to fully shut down. 17 seconds later, it's stupidly still posting its status as "alive" to any interested UPnP servers. Serviio dutifully responds.
23:51:39 - Having now decided, "what the hell, may as well go full retard," the 360 tosses a GET /deviceDescription to Serviio. Again, Serviio dutifully works to respond, but by the time it's in the middle of sending the response, the 360 finally keels over dead.

And, voila. The connection to port 64053 remains hung. It's worth noting that I have another log of this process, where the hung connection's target port does NOT match the port that made the final GET call, so even in its unreliability, it's not fully reliable.

tl;dr: Stupid machine is stupid.