kennyw.com Open in urlscan Pro
208.113.159.25 Public Scan

Back to summary

URL:
https://kennyw.com/?m=200708
Submission: On July 21 via api (July 21st 2024, 6:47:36 pm UTC) from US — Scanned from CA

Form analysis
1 forms found in the DOM

GET https://kennyw.com/

<form role="search" method="get" id="searchform" class="searchform" action="https://kennyw.com/">
  <div>
    <label class="screen-reader-text" for="s">Search for:</label>
    <input type="text" value="" name="s" id="s">
    <input type="submit" id="searchsubmit" value="Search">
  </div>
</form>

Text Content

KENNYW.COM

Skip to content
* Home
* Restaurants
* Atlanta, GA Restaurants
* Berkeley, CA Restaurants
* Cambodia Restaurants
* Croatia Restaurants
* Hungary Restaurants
* India Restaurants
* Laos Restaurants
* Los Angeles, CA Restaurants
* Nepal Restaurants
* New Orleans, LA Restaurants
* New York City Restaurants
* Portland, OR Restaurants
* Seattle, WA Restaurants
* Thailand Restaurants
* Vancouver, BC Restaurants
* Vietnam Restaurants
* Whistler, BC Restaurants
* Band Recordings
* Archives

MONTHLY ARCHIVES: AUGUST 2007

SIGNALLING "END OF SESSION"

Leave a reply

When authoring a session-ful channel, it’s important to signal “end of session”
correctly so that the runtime (or any other user of the channel) knows when to
stop reading messages, and to start shutting down his side of the conversation
(with CloseOutputSession and/or channel.Close). A null Message/RequestContext
signals end-of-session to the caller. In particular, depending on your channel
shape, you should do the following:

* IInputSessionChannel/IDuplexSessionChannel: Return null from
channel.Receive(). Correspondingly, return true from TryReceive with the
“message” out-param set to null. And of course, cover your bases by having
BeginTryReceive complete synchronously with a signal to return true + message
= null from EndTryReceive.
* IRequestSessionChannel: Return null from channel.ReceiveRequest().
Correspondingly, return true from TryReceiveRequest with the “context”
out-param set to null. Lastly, have BeginTryReceiveRequest complete
synchronously with a signal to return true + context = null from
EndTryReceiveRequest.

This entry was posted in Indigo on August 23, 2007 by kenny.

THROTTLING IN WCF

17 Replies

When your server is hosted out on the “big bad internet”, you need a way to make
sure that you don’t get flooded with client requests. In WCF, our services
support throttling as a way of mitigating potential DoS (denial of service)
attacks. These throttles can also help you smooth load on your server and help
enforce resource allocations. There are three service-level throttles that are
controlled by ServiceThrottlingBehavior. These are in addition to any
transport-specific throttles imposed by your binding. To fully understand the
impact of these throttles you should also understand the threading/instancing
characteristics of your service.

1. MaxConcurrentCalls bounds the total number of simultaneous calls that we
will process (default == 16). This is the only normalized throttle we have
across all of the outstanding reads that the ServiceModel Dispatcher will
perform on any channels it accepts. Each call corresponds to a Message
received from the top of the server-side channel stack. If you set this high
then you are saying that you have the resources to handle that many calls
simultaneously. In practice how many calls will come in also depends on your
ConcurrencyMode and InstancingMode.
2. MaxConcurrentSessions bounds the total number of sessionful channels that we
will accept (default == 10). When we hit this throttle then new channels
will not be accepted/opened. Note that this throttle is effectively disabled
for non-sessionful channels (such as default BasicHttpBinding).

With TCP and Pipes, we don’t ack the preamble until channel.Open() time. So
if you see clients timing out waiting for a “preamble response”, then it’s
possible that the target server has reached this throttle. By default your
clients will wait a full minute (our default SendTimeout), and then time out
with a busy server. Your stack will look something like:

> TestFailed System.TimeoutException: The open operation did not complete
> within the allotted timeout of 00:01:00. The time allotted to this
> operation may have been a portion of a longer timeout.
> […]
> at
> System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.SendPreamble(IConnection
> connection, ArraySegment`1 preamble, TimeoutHelper& timeoutHelper)

If instead you are timing out under channel.Send (rather than channel.Open),
then it’s possible that you are hitting the MaxConcurrentCalls throttle
(which kicks in per-message, not per-channel).

3. MaxConcurrentInstances bounds the total number of instances created. This
throttle provides added protection in the case that you have an instance
lifetime that is not tied to a call or a session (in which case it would
already be bounded by the other two throttles). Orcas durable services are
one such scenario.

Net-net: if you are testing your services under load, and your clients start
timing out, take a look at your throttling and instancing values. On the flip
side, do not just blindly set these to int.MaxValue without fully understanding
the potential DoS consequences.

This entry was posted in Indigo on August 6, 2007 by kenny.
Search for:

kennyw.com Open in urlscan Pro 208.113.159.25 Public Scan

Form analysis 1 forms found in the DOM

GET https://kennyw.com/

Text Content

kennyw.com Open in urlscan Pro
208.113.159.25 Public Scan

Form analysis
1 forms found in the DOM