views:

500

answers:

4

I'm building a network server and starting a lot of AppDomains on the server to which requests are routed. What will be the fastest way to send off a request payload to one of the AppDomains for processing?

  1. Read in the payload from the socket into a byte array and marshal it.
  2. Marshal the network stream (inherits from MarshalByRef) to the AppDomain.
  3. Read the payload. Decode it into objects. Marshal the decoded objects.
  4. Use named pipes to transfer the byte array.
  5. Use loopback sockets.
  6. Maybe there is a way to marshal the actual socket connection?

The decoding mostly creates immutable objects that are used to determine how to fulfill the clients request and the AppDomain then creates a response and marshals it back to the host AppDomain which sends it back through the socket.

The method should prefer less memory over less CPU.

WCF is not an option.

+1  A: 

TCP binary remoting is certainly fast, I do not how much faster it is than raw sockets which is probably the fastest, but a royal PIA.

I have run 1500 - 2000 req per second in production using HTTP binary remoting between two boxes. On the same box you should have much high performance using TCP or a name pipes channel, depending in the CPU cycles it takes to process the data.

Gary
+1  A: 

If I was you I would take a look at how Cassini is implemented. It does pretty much exactly what you are talking about doing.

Actually Cassini has been sort of superceded by Webhost which is the built-in webserver that ships with Visual Studio now. Take a look at this post on Phil Haack's blog for more.

Alex James
Cassini listens for connections in the remote AppDomain. It seems OP wants to listen on socket on the default AppDomain.
Vadmyst
A: 

Very good question. If I were coming at this problem I would probably use a Buffered Stream / Memory Stream and marshal the stream into the AppDomain that consumes the object to reduce marshaling or serializing many object graphs that were created in a different AppDomain.

But then again, it sounds like you are almost completely duplicating the functionality of IIS, so I would look/reflector into the System.Web.Hosting namespace and see how they handle it and their WorkerThreadPool etc....

Chad Grant
A: 

6 .Maybe there is a way to marshal the actual socket connection?

6-th is IMO the best option. Socket from process perspective is just a handle. AppDomains reside in single process. That means that appdomains can interchange socket handles.

If socket marshalling is not working, you can try recreating socket in other appdomain. You can use DuplicateAndClose to do this.

If that will not work, you should do some perfomance testing to choose the best data transfer method. (I would choose named pipes or memomry mapped files)

Vadmyst