what is the relation between those properties? which one of them govern the number of clients connect to net.tcp reliable service?
I tried to read on both of them but tit is not clear which control what in the throtlling of the service
Hope this is helpful.
MaxPendingChannels has to do with the number do number of clients that can connect to a service via reliable session.
When the sender creates a reliable session channel to a receiver, a handshake between them establishes a reliable session. After the reliable session is established, the channel is put in a pending channel queue for acceptance by the service. The MaxPendingChannels property indicates how many channels can be in this state.
MaxConnection behavior depends if it is set on the client or the server: On the client, it's a limit on the connections that are pooled, and on the server it's a limit on connections that haven't been accepted yet by the ServiceModel layer, ref
In my opinion, this property describes the same thing, the number of channels that clients can connect to at the same time. With one difference, the default Concurrencymode for the WCF service is concurrencymode.single, which limits the number of connections a customer can make. In this mode, maxconnection represents the maximum number of connections allowed to be pending dispatch on the server, and maxpendingchannels refers to the number of connections for a reliable session.
Related
I am trying to find an option in ActiveMQ (5.13) that would allow me to configure the broker with a maximum number of amqp connections from one client. The target is to prevent one malicious or malfunctioning client to consume all the connections available on the broker preventing other clients to connect.
I am aware of the possibility to set maximumConnections on the transportConnector, but, as long as I understand correctly, this is a global limit on all the connections so it would not help in this case.
Is my understanding of the maximumConnections correct?
Is there a way to configure maxConnections per client on the broker?
No, there is no such property for a per client limit in ActiveMQ. You'd first need to narrow down what you define as a single client as that can be defined differently by different people. IP Address might not work as there can be several different applications coming from a single address depending on network topology or application co-location within a single box etc.
I have a question with regards to WCF client channel lifetime while using Message security, but first, a few notes on my company's setup and guidelines:
Our client-server applications are solely for intranet use
Our clients are WPF applications
Our company's guidelines for WCF usage are:
Use wsHttpBinding
Use Message Security
Service InstanceMode: PerCall
Service ConcurrencyMode: Multiple
It is the first time I have to use message security on an intranet setup. Here's how I typically use my client channels to limit the amount of resources kept on the client and server and literally just to keep things simple:
Instantiate + open channel (with ChannelFactory)
Make the WCF call
Close / dispose the channel asap
While monitoring this strategy with Fiddler 2, I noticed that because of Message Security, a single WCF call ended up causing 5 round-trips to my service:
3 initial round-trips for handshaking
1 round-trip for the actual WCF call
1 call to close the session (since I am using PerCall, I am assuming this is more a security session at the IIS level)
If I were to turn off Message Security, as one would expect, one WCF ended up being... A single round-trip.
As of now, I must use Message Security because that's our guideline. With this in mind and knowing that we make hundreds of WCF calls from each client WPF app a session, would you therefore advise to open the client channel and keep it open for re-use instead of disposing of it every time?
I would advise not to preemptively turn off features until you know they are a known problem. Preoptimization is needless work. Until you notice your clients having lagging problems, I would not worry about the message security. At that point, try a few things: one of your approaches of keeping a client open longer; two, try grouping requests together without turning off message security; three, consider caching, if you can; four, if the message security is the final culprit, then try a different method. I wouldn't just turn something off because I see a bit more network traffic until I knew it was the absolute last thing that I could do to improve performance.
I've just read about how WCF can send reliable messages and I wanted to check something.
If the WCF service is set to use Reliable Messaging and a client requested some data from a service. If the client had been hacked to keep saying this data not received would the WCF service keep resending the data indefinitely? Could this be used to affect the stability of the server and is it a risk?
Are there security measures which should be put in place if the WCF service is public?
I suppose it's not much worse than clients clicking refresh on a webpage. But is there anything else which should be considered?
There is a MaxRetryCount property:
This value, which defaults to 8
(minimum 1, maximum 20), specifies how
many times the infrastructure shall
retry to resend a message in case of a
transmission failure. Once a message
has been unsuccessfully resent for the
configured number of retries, the
failure is considered to be
unrecoverable and causes the channel
to fault.
Book Essential WCF claims that NetTcpBinding.MaxConnections limits the number of connections to an endpoint. Thus if property is set to value of 10, then only 10 concurrent connections will be allowed to that endpoint.
But the following blog http://kennyw.com/work/indigo/181 claims this property this property doesn’t limit the number of concurrent connections, but instead only specifies max number of connections that will be cached and reused by another channel:
MaxConnections for TCP is not a hard
and fast limit, but rather a knob on
the connections that we will cache in
our connection pool. That is, if you
set MaxConnections=2, you can still
open 4 client channels on the same
factory simultaneously. However, when
you close all of these channels, we
will only keep two of these
connections around (subject to
IdleTimeout of course) for future
channel usage. This helps performance
in cases where you are creating and
disposing client channels. This knob
will also apply to the equivalent
usage on the server-side as well (that
is, when a server-side channel is
closed, if we have less than
MaxConnections in our server-side pool
we will initiate I/O to look for
another new client channel).
So which is true?
EDIT:
First of all, you mean NetTcpBinding.MaxConnections, right?
Yes, thank you ... I've corrected the typo
See official docs at http://msdn.microsoft.com/en-us/library/system.servicemodel.nettcpbinding.maxconnections.aspx and especially http://msdn.microsoft.com/en-us/library/ms731078.aspx - the behavior is actually different depending if it's the server or the client, but in no case is it a hard limit on the number of connections. (On the client, it's a limit on the connections that are pooled, and on the server it's a limit on connections that haven't been accepted yet by the ServiceModel layer).
a) I assume by “pooled” you mean number of connection that will be reused by other channels. But the blog says this is the case for both client and the server, while if I understand you correctly, you’re saying on server it means number of connections waiting to be accepted by ServiceModel layer?
Thus if property is set to 10, then only 10 connections will be allowed to wait to be accepted and if another connection tries to wait, it will immediately be rejected?
First of all, you mean NetTcpBinding.MaxConnections, right?
See official docs at http://msdn.microsoft.com/en-us/library/system.servicemodel.nettcpbinding.maxconnections.aspx and especially http://msdn.microsoft.com/en-us/library/ms731078.aspx - the behavior is actually different depending if it's the server or the client, but in no case is it a hard limit on the number of connections. (On the client, it's a limit on the connections that are pooled, and on the server it's a limit on connections that haven't been accepted yet by the ServiceModel layer).
I have a Windows service that logs speed readings from a radar gun to a database. In addition, I made the service a WCF server. I have a Forms and a CF client that subscribe to the service and get called back whenever there is a reading that satisfies certain criteria.
This works in principle, but after some time the channel times out. It seems that there are some fundamental issues with long-running connections (see
http://blogs.msdn.com/drnick/archive/2007/11/05/custom-transport-retry-logic.aspx) and a duplex HTTP callback may not be the right solution. Are there any other ways I can realize a publish/subscribe pattern with WCF?
Edit: Even with a 2 hour timeout the channel is eventually compromised. I get this error:
The operation 'SignalSpeedData' could not be completed because the sessionful channel timed out waiting to receive a message. To increase the timeout, either set the receiveTimeout property on the binding in your configuration file, or set the ReceiveTimeout property on the Binding directly.
This happened 15 minutes after the last successful call. I am wondering if instead of keeping the session open, it is possible to re-establish a fresh session for every call.
Reliable messaging will take care of your needs. The channel reestablishes itself if there is a problem. WSDualHTTPBinding provides this for the http binding, and there is also a tcp binding that allows this. If you are on the same computer, named pipe binding will provide this by default.