I was on-site with a client at a pharamacutical production facility last week and they they showed me a strange problem that they were having with .NET Remoting running on a sub-network configured with a multihomed host that sits on both the sub-net and the factory ethernet.<\/p>\n
\u00a0<\/p>\n
The sub-network consisted of 11 Machine Vision inspection station PCs that happily inspect product on the production line and report their results and status asynchronously to a single ‘dashboard’ system running on the multi-homed host. We had developed the inspection stations with vanilla C++ and the ‘dashboard’ system in C# .NET, they all communicate via .NET Remoting.<\/p>\n
\u00a0<\/p>\n
The dashboard system connects to each of the inspection stations in turn and passes a remoting object of a shared interface, the inspection stations raise events across the sub-net by calling back on this shared interface.<\/p>\n
\u00a0<\/p>\n
All was well with\u00a0tonnes of nice events being raised and received, until one day\u00a0they all just stopped! The client was sure that nothing could have changed to cause this as the whole system was under qualification and therefore everything (software\/configuration etc.) must stay static. However on further investigation it turned out that the dashboard PC had recently been added to the factory ethernet – and sure enough, once the factory network was whipped out and the dashboard restarted the events came flooding back!<\/p>\n
\u00a0<\/p>\n
Anyway it seems that when the dashboard system was connected to the factory network it\u00a0communicated to the inspection stations using its factory NIC identity and IP address.\u00a0 When\u00a0the stations tried to callback they used this factory IP address and the callback events were lost as the PC\u00a0knew of no\u00a0 way to route the traffic onto the factory network (and hence back to the dashboard system).\u00a0 On further investigation we found that the inspection station PCs (which were given static IP addresses) did not have a default gateway configured so we configured the dashboard’s local IP address as the gateway for each and the problem was solved!\u00a0 This change ment that any network traffic destined for any network other than the local sub-net would be automatically sent to the dashboard system.<\/p>\n
So, to cut a long and boring story short, if you’re having .NET remoting callback problems with a multihomed host take a look at the network configuration and\u00a0make sure that t he PCs that raise the events are able to route them back to the receiver PC no matter which network it initially calls on..<\/p>\n","protected":false},"excerpt":{"rendered":"
I was on-site with a client at a pharamacutical production facility last week and they they showed me a strange problem that they were having with .NET Remoting running on a sub-network configured with a multihomed host that sits on both the sub-net and the factory ethernet. \u00a0 The sub-network consisted of 11 Machine Vision […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[57,83,84],"class_list":["post-71","post","type-post","status-publish","format-standard","hentry","category-tech-stuff","tag-net","tag-net-remoting","tag-multihomed-host"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t