[Mono-dev] Keep-alive connection with Remoting?

[Ympostor]

Rafael Teixeira wrote:
> You have to choose the server state-model and configure the Lifetime
> policy in the server. The default even for the singleton state-model
> is to kill the server object after a few minutes and recreate on the
> next request from the client.

Thanks for the guidance. I said that I had overriden the LifeTimeService 
method in the clients. I made it on the server with no luck, but after 
that I realised that I had to do it also on the MarshalByRefObject 
object used in the Reachability sources, then all time-out problems 
disappeared.

> It is a design-for-scalability decision MS did for remoting, as
> long-living server objects (and also connections) are some of the
> worst enemies of scalability.
> 
> As you said scalability is a concern for you, I need to warn that you
> are actively working against it by choosing persistent connections,
> and long-living server objects.
> 
> My experience is that persistent connections put a ceiling (and a
> really low one) on how much you can scale, something like a few
> hundred to a thousand simultaneous connections depending in the OS and
> network I/O efficiency of the hardware.
> 
> Long-living server objects strain memory usage and thus garbage
> collection (even causing server hiccups), when you try to scale up,
> but surely, how fast it breaks is dependent on the memory consumption
> of all the chain of objects needed by your server object to service a
> request, so it is more tied to your specific implementation than the
> persistent connections issue.
> 
> Just some facts I learned from a long life is this business, and that
> I teach my post-graduation students in return.

Really interesting thoughts but I have some questions:

- If long-living service is used, are you saying that its dead objects 
won't never be collected until the service dies for any reason?
- If I had to deal with scalability issues, how could I use a not 
long-living service without loosing the connection with the clients? I 
am thinking of ordering them to disconnect and reconnect again but, 
wouldn't this consume so many resources and processor cycles (and time 
in which the server is not available for incoming connections) if we are 
treating with ~1000 clients...?

However, my main concern now is to make it work and then lately solve 
any scalability issues. And then, my update about the progress, if 
anyone is interested:

As I said, I already changed the sources to 2.0 API and to work with 
long-living connections, but now I am stuck with a very stupid problem: 
I just want to implement a similar method to "SendMessage" but that 
sends a file to the client, but I don't know why it works only sometimes:

- In the same host, one client and one server, it works (the file is 
received).
- Same host, two clients and one server, one client receives the file 
and the other client receives the first notification but doesn't end the 
method to save the file. :?
- Host A with server, host B with client. If I send a normal message the 
communication works, but if I try to send the file, there is no 
communication. :?

I am becoming crazy... Perhaps in the end this is not a very stable 
solution.

BTW I have found two more solutions:

a) PeerChannel [ 
http://www.mailframe.net/Products/PeerChannel/default.aspx ]

It seems to be free but:
- I haven't managed to make it work yet (NullReferenceException thrown 
at the middleware channels, not in the client or server...? perhaps 
again due to 1.1 vs 2.0 problems...).
- Not all source is attached in the ZIP. There is a 
MailFrameDataStructures.dll that doesn't come with the source!


b) DotNetRemoting SDK [ http://www.dotnetremoting.com/ ]

Again, commercial, and seems not to be very popular (I have read some 
criticism about this library...).


Regards.