Guidance for using Events and delegates in Remoting
Events and Delegates are supported in remoting. So x-appdomain and x-process delegates and eventing does work. The guidance is to not use them in cases where channels could be unreliable. In case where channels are unreliable (mostly the network in x-machine cases) its difficult to handle exceptions when events are being fired ( An unhandled exception handler might be able to handle these though). They also could lead to scalability issues when multiple events are being fired in short durations. A better design is to have a pull style pattern, than the push patterns like events. Clients can query the server rather than server calling back to clients.
That said, for x-appdomain case events / delegates should work as expected though and the new IPC channel in v2.0 could also be suitable when using these. But please use caution while using events over remoting in your application design.
Comments
- Anonymous
October 16, 2004
In my experience, routers are a MUCH bigger problem.
If your client application is running behind a router (as in the case of most home networking setups), there is no way for the server to dispatch events to the client. Opening ports on your firewall doesn't help, because there's no way for remoting to find the client's IP address in anything but the most limited of senarios.
I had to rip out huge blocks of code and completely rearchitect the application when we went from testing with all machines on the same LAN to a real-world configuration. This was a major problem for us.
The failure of .NET remoting to work with NAT routers is simple inexcusable. Yes, it's a hard problem, I understand that, but it basically means you can't use .NET remoting unless you have total control over the network topology now and forever in the future. That's an unrealistic assumption to make about your network in many (most?) cases, which means that you basically can't use .NET remoting.
With all the work that went into designing .NET remoting, it sure would be nice if it had ended up as a usable feature.
-Don - Anonymous
October 16, 2004
Yes this has been an issue, not just for events but for regular client callbacks as well. In general the guidance has been to use remoting in very near environments, either on same machine or within the same network.
Also, didnt clients listening on wellknown ports work for your scenario?
Thanks - Anonymous
October 16, 2004
Mind you, the NAT problem is not inherent to .NET Remoting, but rather to the implementation of the TCP channel in the framework. You could write your own channel handler, and get the result you desire. This would require no code changes to your main code -- well, you'd need to specify the new channel, of course, but hopefully you were using the standard remoting XML config that you drop in app.config.
Now, I've never used this product, and I most certainly don't work for the company, but I've seen good posts about it: http://www.genuinechannels.com/. Rather than write your own channel, as I describe, you can buy one. In particular, it talks about how it is NAT friendly. The licensing terms, at first glance, seem pretty good. - Anonymous
October 16, 2004
>didnt clients listening on wellknown ports work for your scenario?
Unfortunately not.
Problem #1)
Behind a NAT router, each machine generally only knows its non-routable address (eg. 192.168.1.100). That address works fine for other hosts behind the same NAT, but it's useless for machines on the other side of the NAT.
.NET remoting tries to send the events to 192.168.1.100, when they need to be sent to the external address of the router (such as Gateway.MyBigCompany.com or JohnsHomeRouter.Comcast.net).
It's possible using .NET remoting configuration to specify another IP address (different from the machine's IP address), but that assumes that the machine (or the user) has a way to find the IP address of the gateway. Most home users probably have no idea how to look up the IP address of their cable modem, and certainly can't be expected to remember to from with a .config file every time they power cycle their modem.
In a corporate setting, there is hopefully an admin somewhere who knows how to find the IP address of the offending NAT router, but again it's (IMHO) unrealistic to expect the .config files to be maintained correctly across arbitrary network topology changes.
Problem #2)
Assuming that you've found a way to get the correct IP addresses into the remoting config file, and assuming that you have confidence that the configs will be updated correctly following any network topology changes, then you can start worrying about port numbers.
The problem here is that one typically has a NAT router because one is going to have an arbitrary number of machines behind it. Might be one or two, might be more. The router makes it easy to add more.
Unfortunately, a separate port (or set of ports) needs to be assigned to each client machine that lives behind the router and wants to use the service. As machines are added and removed, the router configuration tables must be manually modified. Perhaps in a large corporate environment this can be automated, but in a home/small office setting it will be a manual process (and if I ran a big corporate firewall, I'd certainly be nervous about automated processess having the ability to open ports on my firewall).
Once all those ports have been opened, the port assignments need to be copied into the .NET remoting config files on the various machines that want to receive events, so that they can tell the remote machine not just the external IP address of their router (from Problem #1), but also the external port number that is being routed to their machine.
It's completely unrealistic to expect all but the most sophisticated of MIS departments to be able to manage multiple distributed config files and router settings over any length of time (sure, they might be able to set it up initially, but will it still be functioning five years later after an employee turnover cycle or two?)
----
> http://www.genuinechannels.com
Like Todd, I've seen posts regarding genuinechannels but have never used it. It might be a great product and it might be a great company, but I can't allow an architecture to be 100% dependent on a 3rd party library without doing considerable research on both the library and the company.
I didn't have time for either, so I had to rip out remoting. I had also (naively) assumed that Indigo would fix this problem, but the impression I've gotten from back-channel conversations with people on the MS remoting team is that it's not going to be fixed in Indigo.
I certainly hope that MS fixes this issue for Indigo (or buys GenuineChannels). Until then, there's no way that I can possible allow the use of .NET remoting, nor could I recommend it's use to anyone else. On the surface, it looks like a fabulous technology, but in practice it's entirely useless for all but the most trivial of network topologies.
-Don
ps. I appologize for the sounds of flaming in my post, remoting burned a huge amount of resources first in architecting the solution to use it, then in uncovering why the solution broke when it hit a real-world network, and finally in re-architecting the solution with zero remoting so as to work on the real-world network. I'm angry that MS allowed a defective library like this to make it into .NET, and I'm even more angry that none of the books or articles that I read on remoting while architecting this application made any reference to the NAT router problem. I don't like having my time wasted, and I fear for all the other developers who will have their time wasted in exactly the way that we did. - Anonymous
October 16, 2004
Hi Don,
For exactly the reasons you list and a few others, the guidance has always been to not use client callbacks including events and delegates. As I mentioned before remoting is a suitable option mainly for same machine and intranet style applications (where you could control the network). For internet scale applications asmx web services is what you should be considering
Thanks for your feedback, I will send it over to the Indigo team - Anonymous
October 16, 2004
> the guidance has always been to not use client callbacks including events and delegates
It's nice to see that in print, and maybe that guidance is well known within Microsoft or within the Remoting team, but I certainly never encountered it in any of the books or MSDN articles that I read on remoting (and I read multiple books and countless articles on remoting while designing this application)
Googling for
site:microsoft.com remoting nat
Brings up a mere 57 links, the vast majority of which are either irrelevant or pertain to securing networks.
It is a huge stretch to say that "the guidance has always been to not use client callbacks including events and delegates."
The developer community outside of Microsoft has no way to know that this guidance exists or that the problem exists, until they encounter it on their own.
> Thanks for your feedback, I will send it over to the Indigo team
It sure would be great if they would do something about this. I'm generally a huge fan of Microsoft and .NET, and I'd very much like to be able to use remoting-like technology in the future.
-Don - Anonymous
October 17, 2004
I'd love to see support in .NET remoting channels for automatic handling of UPnP. This would help to address some of Don's needs. Now, granted, not everyone has a UPnP NAT router, and many that do have UPnP routers have UPnP turned off (due to past security issues and fears), but I think it would be a step in the right direction.
It seems that the vast majority of home-targeted routers are UPnP aware; I'm unsure what percentage of these have UPnP turned on my default. But I do get the sense that home-based UPnP usage is growing. (For example, I've noticed that most modern P2P applications, especially Bittorrent clients, now have specific support for UPnP due to user demand. Granted, these users are a more techincal subset of the user community as a whole. But these are the same folks that configure the home routers in their relative's homes...) - Anonymous
February 15, 2006
Manish et al,
I've run across an interesting anomaly recently with regards to client callbacks. I note the guidance above to avoid using client callbacks x-machine, yet I am curious if others have had success with it. It works fine for me but for one issue...
Consider the scenario where you have a distributed LAN application, with server callbacks (events) to registered clients on the LAN. When the client establishes a typical remoting connection (http channel, binary formatter), an available port is automatically selected and the client IP address is automatically included in the marshalled object ref given to the server. Unfortunately, that IP address can be incorrect in the case where you have multiple network adapters installed. So your callbacks then may be attempting to contact a totally bogus IP address. Sadly, the logic seems to depend on the ordering of the active network adapters.
One can work around this by explicitly specifying the client callback IP address in the remoting connection information, but this requires that config files be updated for each client whenever their IP addresses change.
How is it that the client IP address being marshalled to the server might be extracted from a network adapter other than the one used to contact the server? This makes little sense. Does WCF introduce anything new/helpful along these lines?
Thoughts appreciated.