1. object AsyncState
2. WaitHandle AsyncWaitHandle
3. bool CompletedSynchronously
4. bool IsCompleted

1. protected AsyncCallback AsyncCallback - "Caller's callback method"
2. internal object AsyncObject - "Caller's async object"
3. internal object Result - "Final I/O result returned by the End* method"
4. internal int ErrorCode - "Win32 error code for Win32 IO async calls (that want to throw)."

1. internal bool EndCalled - "True if the user called the End*() method" [what? the user calls their own end method?]
2. internal bool InternalPeekCompleted - "Returns true if this call created the event." [what???]
3. internal void InvokeCallback()
4. internal void InvokeCallback(object result)
5. protected void ProtectedInvokeCallback(object result, IntPtr userToken) - "A method for completing the IO with a result and invoking the user's callback. Used by derived classes to pass context into an overridden Complete()." [note: ProtectedInvokeCallback calls into Complete() if the async result had not been completed yet.]

• internal void InternalCleanup() - "A general interface that is called to release unmanaged resources associated with the class. It completes the result but doesn't do any of the notifications."
• internal object InternalWaitForCompletion() - "If [AsyncWaitHandle] is used, the [manual reset event] cannot be disposed because it is under the control of the application. Internal should use InternalWaitForCompletion instead - never AsyncWaitHandle"

Just add this to your .csproj (or .props or .targets file depending on how you're structuring your build).

    <!-- note: This controls what files *related to a DLL* are copied to the output directory with the dll.
         Setting custom AllowedReferenceRelatedFileExtensions to just .pdb and .pri - EXCLUDE .xml so that
         all sorts of giant intellisense XML files are not copied to the bin directories!
         You can override this per-project if you really want the .xml files for some reason -->
    <AllowedReferenceRelatedFileExtensions>
      .pdb;
      .pri
    </AllowedReferenceRelatedFileExtensions>

Of course once I discovered the variable, it was *easy* to find many other people already knew about this. I was just failing to find it, sigh.

Example: https://stackoverflow.com/questions/2011434/preventing-referenced-assembly-pdb-and-xml-files-copied-to-output

What does this code do?

    class FO : IEnumerable
    {

        public IEnumerator GetEnumerator()
        {
            throw new NotImplementedException();
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            var cb = new ContainerBuilder();
            cb.Register(ctx => new FO()).As<IEnumerable>().InstancePerLifetimeScope();
            cb.Register<Func<FO>>(ctx => { return () => new FO(); }).As<Func<IEnumerable>>();
            var x = cb.Build();
            using (var s = x.BeginLifetimeScope())
            {
                var f = s.Resolve<Func<IEnumerable>>();
                var i1 = f();
                var i2 = f();
                var ie = x.Resolve<IEnumerable>();
            }
        }
    }

In particular

Are i1, i2, and ie distinct?

What if you comment out the line cb.Register<Func<FO>>(ctx => { return () => new FO(); }).As<Func<IEnumerable>>();?

OK let me explain. I never registered anything as Func<IObservable<object>> and yet the below code still works. It turns out to be that not only does autofac understand Func<Dependency>(), it understands a whole bunch of things that you may or may not have intended to be dependency relationships. :)

The details [Copied straight from https://autofac.readthedocs.org/en/latest/resolve/relationships.html]

So now I know!

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Autofac;

namespace IsAutoFacMagical
{
    class CO : IObservable<object>
    {
        public IDisposable Subscribe(IObserver<object> observer)
        {
            throw new NotImplementedException();
        }
    }

    class DO
    {
        public Func<IObservable<object>> Magic { get; set; }
    }

    class Program
    {
        static void Main(string[] args)
        {
            var cb = new ContainerBuilder();
            cb.RegisterType<CO>().As<IObservable<object>>();
            cb.RegisterType<DO>().PropertiesAutowired();
            var x = cb.Build();
            var d = x.Resolve<DO>();
            var m1 = d.Magic();
        }
    }
}

Principle #1 - Keep serialization knowledge where it belongs - in your data access layer!

Problem manifestation #1: we were using Entity Framework with string fields and effectively storing enumeration values as strings. What this tends to lead to is little bits of smelly code everywhere like the following:

deployment.Status = DeploymentStatus.Active.ToString();

if (String.Equals(deployment.Status, DeploymentStatus.Suspended.ToString());

DeploymentStatus status = (DeploymentStatus)Enum.Parse(typeof(DeploymentStatus), deployment.Status, true);
switch (status) {...}

Problem manifestation #2: we were also using Entity Framework to store json serialized dictionaries of settings....

Solution:

Fix the model. Make the code model really have an enum DeploymentStatus property, and a Dictionary<string,string> Settings property. Change the data abstraction layer to be what knows how to serialize that to and from a string in the database column, and then hurray! You can remove those ToStrings() and Parses() from code everywhere.

Principle #2 - Query objects can be testability goodness!

Problem manifestation: (Basically we were half-way there, but realizing none of the benefits, leading to brittle mocking code.)

Again with the Entity Framework, we had a bunch of smell test code which would be (Test code before:)

var resourceSpec = new ResourceSpecification(resourceName, otherQueryParameters);
var fakeStore = A.Fake<DeploymentStore>();
A.CallTo(() => fakeStore.GetDeployment(resourceSpec)).Returns(new Deployment { ... });

For all our methods which needed to do some action on an existing deployment, they would take either a ResourceSpecification or a bunch of string parameters, then look up the deployment, then do some stuff with it. Testing them was a PITA because you are constantly jumping through the hoop of 'how do I mock out the retrieval of the actual Deployment resource from the database'?

Code before:

var deployment = _context.GetDeployment(resourceSpec);

Code after:

var deployment = resourceSpec.GetDeployment(_context);

Test code after:

var resourceSpec = new MockResourceSpecification(new Deployment { });

Principle #3 - Resolve Queries for objects up-front at the input validation layer, then the actual work can be done

This may remind you of the 'query command separation' principle...
Code pattern to avoid:

function DoSomethingWithDeployment(ResourceSpecification r, blah, blah, blah)
{
    ...
    CallOtherFunction(r, blah, blah, blah)
    ...
}

function CallOtherFunction(ResourceSpecification r, blah, blah, blah)
{
    Deployment d = r.TryGetDeployment();
    if (d == null) throw new DeploymentDoesn'tExistException();
}

Code pattern to use:

function DoSomethingWithDeployment(ResourceSpecification r, blah, blah, blah)
{
    Deployment d = r.GetDeploymentOrBust(); //throws an exception if deployment doesn't exist
    ...
    CallOtherFunction(d, blah, blah, blah);
    ...
}

Why is the second code so much better than the first? Because it's now much easier reasoning about and testing the code path for deployment doesn't exist.
-validation code is all right there in the function taking user input, which is where you expect that you have to write validation oriented test cases.
-contract between your functions got clearer and simpler
-the code path it is now one less function deep, so now less test cases for the deeper function!

Self-hosting a web server using owin instead of using IIS is an attractive option to me partly because of the limitations of my own experience: I am not an IIS expert, and console apps seem like they will be a way to complete control over things that matter without having to spend time learning IIS-isms.

However, while the sample code snippets show it is incredibly easy to get started hosting owin in just a few lines of code, and have it call you to implement your application logic through a very simple interface, it leaves a fundamental question - what if I need to understand and control things deeper in the software stack that I am running on? Which for me is currently OwinHttpListener etc.

For instance, recently we had a discussion around security of one such owin hosted HTTPS endpoint for diagnostics/management, and possible DOS attacks. While in our particular case we don't care that much if this particular endpoint goes down due to a DOS attack, we do care if this one little endpoint becomes an easy way to DOS the entire process or machine. How do you know if your self-hosted web application is robust enough to withstand slowloris attacks, or just traffic-based DOS attacks Answering this required me to do some research, and google just didn't seem to have the answers readily at hand, so I spent some time digging through reflector, MSDN, and reading about Windows/HTTP.SYS/IIS mitigations for DOS attacks. Let me now summarize some of the things I think I learned in my research.

1. There only seem to be a few basic strategies to choose from:

Filtering out or blacklisting bad traffic:
-Examples: IP based filtering, request-header-based filtering. The idea here is that you can put a filter in your request pipeline that detects attacking requests/packets somehow by what they look like, and discarding them. Possibly you do this by manually configuring filtering in reaction to an identified DOS attack. In order to do this you must have logs which let you identify what the bad traffic looks like. Possibly you implement some kind of automatic filtering system, which might actually be more of a throttling system...

Throttling traffic:
-You can throttle the server overall and attempt to limit total incoming traffic on your server to what you know your server can handle. The point of this is to stop your application performance degrading by trying to handle too many requests at once...
-At application level, if you're in an authenticated app, you can throttle requests per-user, once you've authenticated their connection...
-You can throttle clients at lower levels again based on something about what the requests you are getting look like, and e.g. only accept a few concurrent TCP sessions per client IP address. You have to be careful with such IP based policies though. Sometimes due to NAT a single IP address can represent thousands of legitimate users...

Out-scaling traffic:
-Throw so much servers and bandwidth into action that you can actually handle all the load coming at you. This one may get expensive, so someone is going to have to weigh up the cost of this vs the cost of not doing this and just being DOSed...

2. In general, your best defense against DOS attacks is a multi-layered one.

At the application level, you can easily write a request handler that throttles the number of simultaneous requests your application instance will try to serve. For instance see answers to:

https://stackoverflow.com/questions/33969/best-way-to-implement-request-throttling-in-asp-net-mvc

But what happens if there are too many requests queued at the next layer below your application, or next piece of server infrastructure in front of your application (think load balancer) waiting to get into your application throttling mechanism, because your application throttling code, even though fast, just isn't handling them fast enough?

BTW. IIS is apparently not vulnerable experimentally to e.g. slowloris. So what about HttpListener?

3. In the case of HttpListener, it is built upon HTTP.SYS and there are already some throttling mechanisms in place, for you to use, with reasonable defaults. But if you are not in IIS and are leveraging HTTP.SYS via the Http Server API you should be able to exercise control too

Here are some of the properties you can theoretically set, once you find the right API:

(per
EntityBody - The time, in seconds, allowed for the request entity body to arrive.
DrainEntityBody - The time, in seconds, allowed for the HTTP Server API to drain the entity body on a Keep-Alive connection.
RequestQueue - The time, in seconds, allowed  for the request to remain in the request queue before the application picks it up.
IdleConnection - The time, in seconds, allowed for an idle connection.
HeaderWait - The time, in seconds, allowed for the HTTP Server API to parse the request header.
MinSendRate - The minimum send rate, in bytes-per-second, for the response. The default response send rate is 150 bytes-per-second.

MaxConnections (per url group)- The number of connections allowed. Setting this value to HTTP_LIMIT_INFINITE allows an unlimited number of connections.

HttpServerQueueLengthProperty (per request queue) - Modifies or sets the limit on the number of outstanding requests in the request queue.

Note the documented defaults are:

Now luckily, if you are using HttpListener you don't have to go read the unmanaged code docs and figure out how to P/Invoke everything, because there is a TimeoutManager on HttpListener which lets you set all these properties via the HttpListenerTimeoutManager class - although they are not as thoroughly documented in the .NET api. But of course the even better news I just implied is just that these default limits exist is already going to be giving your application some sensible filtering and throttling goodness.

4. OwinHttpListener comes with some additional checks and balances you can use for throttling requests at its own entry gate (instead of your application's). The way to do this is

owinHttpListener.SetRequestProcessingLimits(int maxAccepts, int maxRequests);

also, for convenience, owinHttpListener also lets you do SetRequestQueueLimit(long length), which modifies the aforementioned RequestQueueLength property of the Http Server API which for some reason HttpListener does not expose.

In F# there are many different collection-looking syntaxes that compile into something. What do they mean?

{a, b, c, d}, [a, b, c, d], (a, b, c, d), [|a, b, c, d|]

Which is really just another way of asking this:

1) Start small and with a goal. Then iterate a little. I draw this conclusion from hearing about LISP, SmallTalk, Forth, C, C++, Pascal that they didn’t come from really grandiose designs to take over the world. The projects started with some small goal to achieve, and were happy to achieve success for that goal with some very small level of proving a point, or being adopted by a small community. This will help you achieve point 2:

2) Don’t be vaporware - have a real implementation early and make it as available as possible.

3) Be easy to port the compiler and the language. Because otherwise you’re going to be running only on one system, or you’ll be generating code for one system, and systems tend to die off in popularity over time being replaced by new ones. There are a lot strategies that come up as answer to the ‘be easy to port’ criteria:

3a) use a frontend compiler architecture generating C (or other highly portable language) code

3b) generate code for a virtual machine [e.g. PL/0, Forth]

3c) be a very compact language to define, and therefore easy to implement a boostrapper interpreter (e.g. LISP, Smalltalk)

3d) be self-hosting (compiler written in its own language), so that if some small set of core-language features can be ported in a bootstrap compiler, it can then compile your main compiler can

4) Have some major commercial backing to attach to that will promote your language! Seriously, this has helped a lot of languages over time. :)

5) Once you have a few too many implementations, get standardized. Or at least have a draft standard. Or have a single authoritative reference implementation (maybe open source). Otherwise eventually people are going to say your language is too fragmented and they don’t know which flavor to adopt, and with choice overload they probably won’t choose your language at all.

6) Be lucky.

Having read a bunch of stories now, I think I have decided the programming language story I really like is Forth. Because it’s the story of how one stubborn guy can decide he is wasting too much time learning all these languages which won’t let him do exactly what he want with the underlying machine/OS, and decide he only wants to need to know one perfectly powerful and simple language for the rest of his life, and he figures out a way to do just that:

-he defines a simple abstract machine architecture
-he defines a simple and powerful language which supports structured programming and code reuse, without all these other complex features everyone wants to put in their languages
-he writes most of the compiler in self-hosting fashion
-any time he has a programming project he just ports the compiler bootstrapper and virtual machine to whatever architecture, and he can reuse all his knowledge on a brand new system.
-bliss…?

Even if his language never catches on with the mainstream he can still be quite a productive programmer in his language anyway, especially since he can keep tweaking the language to his own liking.

Firsltry, it demonstrates the wrinkle that when reading % processor time you need to specify the instance name of the processor, or the special instance name “_Total”.

Secondly you’ll notice that the % CPU time is a performance counter of type Timer100NsInverse, which results in it showing weird large numbers.

MDSN says “Counters of this type calculate active time by measuring the time that the service was inactive and then subtracting the percentage of active time from 100 percent.”

In other words, it tells you your processor’s IDLE time, as a count of some units of 100Ns intervals, measured over some other arbitrarily sized interval which you presumably need to find out from the counter sample timestamps… complicated, sigh.

I used UltimateTimer for the timer, of course...

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace pcpusher
{
    class Program
    {
        static Dictionary<string, string> CountersToMetrics = new Dictionary<string,string>
        {
            { @"\Processor(_Total)\% Processor Time", "percentProcessorTime" }
         };

        static Dictionary<string, PerformanceCounter> CountersToPC = new Dictionary<string,PerformanceCounter>();

        static void Main(string[] args)
        {
            foreach (var k in CountersToMetrics.Keys)
            {
                 var parts = k.Split(new []{'\\'}, StringSplitOptions.RemoveEmptyEntries);
                try
                {
                     var safePart = parts[0].Contains("(") ? parts[0].Substring(0, parts[0].IndexOf("(")) : parts[0];
                     var pc = new PerformanceCounter(safePart, parts[1], readOnly: true);
                    if (parts[0].Contains("(_Total)"))
                    {
                        pc.InstanceName = "_Total";
                    }
                    CountersToPC.Add(k, pc);
                }
                catch (Exception e)
                {
                    Console.WriteLine("can't get PC: " + k + " " + e.Message);
                }
             }

            using (var timer1 = UltimateTimer.ThreadPoolTimer.Create(onTimer1))
            {
                timer1.SetTimer(DateTime.Now, 1000, 10);
                Console.WriteLine("Press any key to end process");
                Console.ReadLine();
                timer1.Close();
            }
         }

        private static void onTimer1()
        {
             foreach (var k in CountersToMetrics.Keys)
            {
                 try
                {
                    var sample1 = CountersToPC[k].NextSample();
                    Console.WriteLine(k + " @ " + sample1.TimeStamp100nSec + "(" + sample1.CounterType + ")" + " : " + sample1.RawValue);
                }
                catch (Exception e)
                {
                     Console.WriteLine(k + " couldn't read " + e.Message);
                }
            }
        }
    }
}