Sockets and AppDomains

[Eyal Post]

Anyone know if it's possible to pass a Socket object between appdomain? I
have a server that can host a few AppDomains. The server creats a Socket and
listens for requests. Whenever a request comes in, the server will read the
request parameters and needs to dispatch the request to a different
AppDomain. The other AppDomain will handle the request but it still needs
access to the Socket to return responses.
Any ideas?

 

[John Saunders]

Anyone know if it's possible to pass a Socket object between appdomain? I
have a server that can host a few AppDomains. The server creats a Socket and
listens for requests. Whenever a request comes in, the server will read the
request parameters and needs to dispatch the request to a different
AppDomain. The other AppDomain will handle the request but it still needs
access to the Socket to return responses.
Any ideas?

This sounds a lot like a UNIX daemon.

AppDomains are usually implementation details. Do you have a particular
reason for giving AppDomains such a prominent place in your design?

In any case, have you looked into using .NET remoting instead of such
low-level techniques as sockets? They work nicely between AppDomains and can
transparently be used between processes or machines, so your design needn't
be limited to AppDomains.

 

[Eyal Post]

The app is similiar to a web server that hosts ASP.Net web applications.
Very similiar to Cassini - but it needs to host multiple web apps. I also
looked at CassiniEx, But it seems he didn't find a solution for this.

Thanks,

 

[John Saunders]

The app is similiar to a web server that hosts ASP.Net web applications.
Very similiar to Cassini - but it needs to host multiple web apps. I also
looked at CassiniEx, But it seems he didn't find a solution for this.

I believe I would still abstract away from sockets. In particular, note that
ASP.NET applications expect to read from a Stream. They do not depend on the
Stream being a NetworkStream. Similarly, they write to an HttpTextWriter,
but don't care what the underlying TextWriter is. You might consider
abstracting the communication down to the Stream level, that is, write your
own Stream class which at the very least hides the socket from the other
AppDomains. You would then get to consider options like having a thread in
the listener AppDomain read the entire request into memory, then handing a
pair of MemoryStreams to the server AppDomains.

I have to say that if I were you I'd still look closely at .NET Remoting. It
can completely abstract away the communication between the AppDomains, while
permitting them to reside in separate processes or even separate machines (a
web garden or web farm).

 

[Eyal Post]

I don't mind pasing a different object (Like NetworkStream) to the 2nd
AppDomain, but it won't solve my problem - i don't want each call to the
network stream to go through the main AppDomain. I'm trying to get the most
in terms of performance and i beleive that marshaling those buffers between
AppDomains may be a problem.
I want to be able to use the connection directly from the AppDomain - i
though about passing the actual Socket handler, but the Socket class does
not have a constructor that takes a Handle.

Thank you for your suggestions.

Regards,

 

[John Saunders]

I don't mind pasing a different object (Like NetworkStream) to the 2nd
AppDomain, but it won't solve my problem - i don't want each call to the
network stream to go through the main AppDomain. I'm trying to get the most
in terms of performance and i beleive that marshaling those buffers between
AppDomains may be a problem.
I want to be able to use the connection directly from the AppDomain - i
though about passing the actual Socket handler, but the Socket class does
not have a constructor that takes a Handle.

Thank you for your suggestions.

I hope I helped some.

My "final" suggestion would be that you shouldn't worry about performance
until you see a performance problem. The cost of marshalling may turn out to
be insignificant. That's why if I were you, I'd design this abstractly at
first. Then you can change implementations without affecting the rest of
your code.