Client/Server event/callback timeout

[Josh]

We have a standard client/server scenario.

Clients connect to a server and subscribe to certain events.
The server fires these events and the clients react accordingly.
The events are not frequent, maybe once a day, sometimes as little as
once a month.

The channel times out after the default 10 minutes. (We're using
NetNamedPipesBinding now, but will be moving to NetTcpBinding as we
scale.)

I found that I can set this timeout value, the ReceiveTimeout property
on the binding (either programmatically or in the app.config file).
(How does this differ from the InactivityTimeout of the
ReliableSession on the binding?)

Obviously in a publish/subscribe scenario we want the clients to be
listening indefinitely. While there is no way to specify an infinite
timeout, I can set it to a maximum value of just over 24 days
(24.20:31:23.6470000). This value is actually not long enough for our
purposes. (Our customers will start a client and leave it running
easily for a month.)

First question: Is this the only way to adjust how long a channel will
listen before closing itself? Surely there are other client/server
applications out there that need to have a permanent channel
established to listen for events?

Second question: Is this really the correct way of establishing a two
way conversation with a server? Once we start to scale up to a few
hundred clients, this means we would have a few hundred permanently
open channels to the server. Will we run into resource problems?

We've also considered that maybe we should make each client its own
WCF server. They would subscribe to the server by sending the name of
their specific channel (endpoint address). When the server had an
event to send it would open up each specific channel to each client
and send the event to the client. Using this method we would not need
to keep a few hundred channel open at a time, nor would we run into
any issues of the channel timing out after 24 days.

Final question: Would this last method work/scale better or are there
other gotcha's with it?

Thanks,
- Josh

[Joe-P]

You are using the ReceiveTimeout correctly. InactivityTimeout is part of
the Reilable Session. It is used when the ordered property is set to true. If
a message has not arrived within a the specified time in the
InactivityTimeout then the WCF Runtime would send a termination message to
the client and then terminates the session and discards all the messages it
recieved during that session.

To acheive the capability of "perpetual" session it would be better for the
client to maintain the session more than having the burden on the server. My
suggestion would be to have a "ping" like a dummy message sent to the server
at a set time hence keeping the session alive. Thereby easing the scalability
issues on the server side.

Post by Josh
We have a standard client/server scenario.
Clients connect to a server and subscribe to certain events.
The server fires these events and the clients react accordingly.
The events are not frequent, maybe once a day, sometimes as little as
once a month.
The channel times out after the default 10 minutes. (We're using
NetNamedPipesBinding now, but will be moving to NetTcpBinding as we
scale.)
I found that I can set this timeout value, the ReceiveTimeout property
on the binding (either programmatically or in the app.config file).
(How does this differ from the InactivityTimeout of the
ReliableSession on the binding?)
Obviously in a publish/subscribe scenario we want the clients to be
listening indefinitely. While there is no way to specify an infinite
timeout, I can set it to a maximum value of just over 24 days
(24.20:31:23.6470000). This value is actually not long enough for our
purposes. (Our customers will start a client and leave it running
easily for a month.)
First question: Is this the only way to adjust how long a channel will
listen before closing itself? Surely there are other client/server
applications out there that need to have a permanent channel
established to listen for events?
Second question: Is this really the correct way of establishing a two
way conversation with a server? Once we start to scale up to a few
hundred clients, this means we would have a few hundred permanently
open channels to the server. Will we run into resource problems?
We've also considered that maybe we should make each client its own
WCF server. They would subscribe to the server by sending the name of
their specific channel (endpoint address). When the server had an
event to send it would open up each specific channel to each client
and send the event to the client. Using this method we would not need
to keep a few hundred channel open at a time, nor would we run into
any issues of the channel timing out after 24 days.
Final question: Would this last method work/scale better or are there
other gotcha's with it?
Thanks,
- Josh

[athoma13]

That's exactly what I am trying to do as well. I was thinking along th
lines of broadcasting a UDP message for events occuring on the server
all the clients would pick that up. (Rather than maintaining a list o
client EndpointAddresses on the server)

--
athoma13