btvagent opens hundreds of sockets

[parisology]

I asked this in another forum but no answer. Is it normal for the btvagent to open tons of sockets? What are they for? They seem to constantly churn on my system, opening and closing constantly, it's sort of a mess if you are doing other network stuff.

[merrypig]

As long as they are being closed why worry?

I've run into some issues on other applications where they didn't close a socket properly and it built up in the tables of my router until it eventually failed routing. That was exacerbated (Go shaun!) by a stupid several hour timeout on the socket by the router. Changing that timeout to minutes solved the problem.

[guncam_man]

Originally Posted by merrypig

As long as they are being closed why worry?

Because minus the guide update, which isn't continuously operating, a DVR should have little use of networking, and the presence of a lot of socket connections indicates a problem.

[merrypig]

No, it demonstrates a lack of knowledge about the product. For example, read up on NetRemoting and inter process communication.

[parisology]

I program .net remoting interfaces in my work, and I know about this. This is why I'm wondering why the btvagent would open hundreds of sockets at the same time. As it starts to open them it reaches some sort of limit, more than 100 I estimate, perhaps up to 200, I haven't counted them. I use sysinternals tcpview to view the connection list. These are all connections to localhost that don't seem to be doing anything. The hard drive churns along in step with this process, which is what first led me to look into it. When this limit is reached it seems to start churning them, for lack of a better term, opens and closes sockets, but the count stays absurdly high.

I wish someone in programming at snapstream could comment on what I'm seeing. Is this normal, expected?

[merrypig]

Well if it counts for anything, the BTV Networking process sits at 2-3% cpu on my box and has done for almost all 4.x releases. I've bugged/complained and otherwise moaned about it officially during beta development and it's never been considered problematic or given a second look.

I suspect it's 'by design', not necessarily desireable, but in short, not going to change.

[nanook105]

Originally Posted by parisology

I program .net remoting interfaces in my work, and I know about this. This is why I'm wondering why the btvagent would open hundreds of sockets at the same time. As it starts to open them it reaches some sort of limit, more than 100 I estimate, perhaps up to 200, I haven't counted them. I use sysinternals tcpview to view the connection list. These are all connections to localhost that don't seem to be doing anything. The hard drive churns along in step with this process, which is what first led me to look into it. When this limit is reached it seems to start churning them, for lack of a better term, opens and closes sockets, but the count stays absurdly high.

I wish someone in programming at snapstream could comment on what I'm seeing. Is this normal, expected?

If you want and answer from support you need to submit a tech support request

[MidnightUT]

I recently posted in another thread. But this one is more appropriate.

Was the cause of this behavior ever discovered?

I've found it mentioned in a few different threads but no responses as to the cause/reason, or a fix for this behavior.

I'm currently running BTV 4.4 and no software firewalls. Is this behavior still evident in the latest version of BTV?

And I understand that this doesn't effect system performance to a great extent. But it shouldn't be normal behavior and I don't want to chance it conflicting with any of the ports used by my other services.

[parisology]

I am trying Link again... it's been a couple of years as you can see from the first post. Link is failing after a while, and tcpview on the host is showing about 256 zombie connections to the Link client. I am trying to at least close the connections down, so far no luck. This has to have something to do with why Link fails. Has it run out of socket connections? I think there is something wrong with the software.

The only way I can reconnect with link is to reboot the host machine... this is way too drastic. Not hoping for a fix of course, I am a realist. If you have a working Link connection that has been up over an hour perhaps you can run tcpview on the host and report the number of connections to the Link client.