Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#4572 closed enhancement (invalid)

allow cccam reader with ccckeepalive enabled to disconnect by inactivitytimeout

Reported by: narsilva Owned by:
Priority: major Component: Reader
Severity: medium Keywords:
Cc: Sensitive: no

Description

Reason for enhancement

Currently if we set a cccam reader for example with ccckeepalive=1 and inactivitytimeout=600, that reader will remain connected forever and not disconnect after 600sec as defined, only if we disable ccckeepalive it will disconnect by inactivitytimeout.
I think it would be a better behavior if the inactivitytimeout ignores the keepalive traffic and still disconnects the reader when no real requests made after the defined inactivitytimeout time.

Ok, if I want it to disconnect why don't I just disable ccckeepalive? Because server on the other side may have a very small inactivitytimeout (example 30sec), then I would expect that enabling ccckeepalive at my side would allow me to not be killed by the server timeout, but still disconnect when reaching my reader inactivitytimeout setting.

Possible impacts on other features

It would allow inactivitytimeout to just work when ccckeepalive is enabled... we should also be able to set inactivitytimeout to 0 if we just don't want it to disconnect at all (i.e. to have the current behavior). Also would be nice if we could also be able to set it to -1 to auto-reconnect on network failure (like for newcamd readers), currently it is not possible for cccam readers.

Change History (3)

comment:1 by pr2, 6 years ago

Resolution: invalid
Status: newclosed

If you enable keepalive this means that you want the connection to remains established forever. And this is a mecanism foreseen in CCcam protocol.
So asking to have a disconnection when keepalive is enable is a total non-sense, untick keepalive and you will have the expected behavior.

The server timeout decision must be respected.

comment:2 by narsilva, 6 years ago

"The server timeout decision must be respected." => seeing it by that point then having keepalive feature itself is non-sense also!?... surely not... my idea was just to allow having keepalive as-is but... (optionally) limited to some time (i.e. the time that we think it's reasonable for our usage, to avoid constant open/close, etc...), I don't see how that would be bad for a server? keepalive forever is surely worst as server will need to keep unnecessary connections all the time...

Also in my idea it can't be directly compared with having no keepalive at all... makes sense that servers kill connections without keepalive by a small timeout time, to avoid eventual "ghost" connections, etc... as I guess there is no traffic at all on these connections, having keepalive packets every x seconds it's different, server knows that the client is there and working... but why it needs to be forever?

comment:3 by ni hao, 6 years ago

"keepalive as-is but limited" is total nonsense. Read what pr2 wrote and you'll have what you want. Just simple as it is: use keepalive or not. No change needed since keepalive=keep alive

Note: See TracTickets for help on using tickets.