replacing MarshalByRefObject with safer option in C#
Asked Answered
I

1

5

I've tried to find a solution at stackoverflow but can't seem to find one quite like mine so here it goes. I have a computer in the lab that is connected to various devices like pan/tilt units, cameras, and light sensors and has all their drivers installed. I have C# code on the lab computer that knows how to talk to the hardware. The C# code can set an exposure time, ask for a picture, get one back, and display it in a picture box. I can tell the pan/tilt to move to a location and have it respond when done. If I am in the lab, it all works just the way I want.

The problem is that I want it to feel like I am at the lab computer when I am really at another computer. Most likely, I will be running the code that is on the non lab computer from inside Visual Studio. The program running in the lab will not be running from Visual Studio. With Remoting, this is a piece of cake. Put the code that talks to the hardware into a class, use MarshalByRefObject along with an interface I create, add RegisterWellKnownServiceType and presto I can use GetObject to get a reference and control it like I was sitting at the computer in the lab. So I know that remoting will work.

However, remoting is being phased out for WCF not to mention its not real safe out in the real world. It appears to me that WCF is going to make a local copy (by value) of the remote object which means it will not be on the lab computer and therefore unable to interact with the hardware that is attached. Someday this lab computer and all the sensor equipment is going to be moved away and I will have to access it remotely using the internet. A couple of years ago I did this exact thing but I was using remoting. Since remoting is so insecure, how do I do this without using remoting? Does WCF not have something equivalent to MarshalByRefObject? If WCF only uses by value, then it seems like they are phasing something out without providing functionality to replace it. Is there a way to use remoting that is not insecure? Is there something else besides WCF I should use?

This may be long winded but I see lots of people get dinged for asking questions that aren't very clear so I am trying to be clear. If there is already a post that truly provides me the best answer to my question, I must first apologize for not finding it myself but ask that a link be provided so I can get the answer there.

Infante answered 2/3, 2015 at 7:1 Comment(5)
Read up of wcf. Its a hassle. Never the less it'll get the job done. I also advice you to look at the tcp binding, streaming and binarymessage encoding if you need your lab computer to react quickly. Wouldn't something like msmq fit your needs much better, its much more lightweight.Cruller
@Cruller agreed tcp is faster but the OP has stated that they will need access via the internet.Somewhere
@TomRedfern true. But the internet actually supports tcp connections :PCruller
Lets me try the 'at' thing we spoke about Tom: @albertjan, I have not done enough research yet to speak knowledgably especially about messaging, so please forgive me if I appear to be speaking nonsense. Having said that, I do want to implement a solution where the client and the server can be on the same machine for those occasions where I am actually working on the lab computer. WCF certainly appears to not care if both are on the same system. I can not say if that is true with messaging.Infante
@Cruller - yes it does providing you can get your required ports to be openned on every router along every hop of the journey - not very likelySomewhere
S
7

It appears to me that WCF is going to make a local copy (by value) of the remote object which means it will not be on the lab computer and therefore unable to interact with the hardware that is attached

This is almost entirely incorrect. There is no "copying" being done across machines. In fact the whole terminology around the "remote object" no longer has much meaning with WCF.

There is no remote object, simply a service. The service exposes operations across it's boundary. Service consumers can call those operations. When a consumer calls an operation, that call passes into the service and can cause the state of the service to change (for example, to talk to some hardware devices).

The service can also send a response to the caller, which can then cause the caller state to change (for example, to display output from the hardware device).

In order to make this happen you first need to create a service definition. Then you need to host your service on the lab machine. Then you need to create a service client, which you can then use on your local machine to call the service operations.

(How to) handle the situation where the port connected to the hardware on the lab computer fires a DataReceived event that needs to be picked up by my application

This is a more complex requirement but yes, WCF supports duplex communications with it's clients.

When you are defining your service contract you can specify that consuming clients implement a callback contract. This forces clients to define a callback operation which is exposed over the communication channel between service and client, and which the service can then call to "push" information to the client.

You should have your service use the WSDualHttpBinding WCF channel binding, which will use port 80 in both directions, allowing this to go across the internet.

Somewhere answered 2/3, 2015 at 11:26 Comment(12)
Thank you Tom. I think I have a much better understanding about how WCF works. It is a completely different way of thinking. So correct me if I am wrong but it seems to behave more like connecting to a website, asking for something (move my pan/tilt), and getting a response. If this is the case, does it handle the situation where the port connected to the hardware on the lab computer fires a DataReceived event that needs to be picked up by my application?Infante
@DaveB no problem - yes you're thinking along the right lines re calling a website. That is effectively what you'll be doing except not using a browser but a client application. Anyhow, I have editted my answer to address your bi-directional communications requirement.Somewhere
@TomRedfern +1 for a beautiful answer. Bravo.Alsatia
Thank you again Tom. I am familiar with using a callback for an event so this should not be too much of a challenge to figure out. I will look into duplex communication and callback contracts to get a better understanding of how those work. I also appreciate the tip about using WSDualHttpBinding and port 80 which is required after my application leaves the lab. I will keep you informed of my progress after I have done some new research. Thanks again for pointing me in the right direction. I feel quite confident now. "+1 for a beautiful answer"Infante
Should I be using @TomRedfern when replying instead of just Tom? I am not sure what that does but the other posts seem to use that.Infante
@DaveB no problem would be interested to hear how you get on. In answer to your question if you comment on someone's post then there's no need to put {at}xxx, they will get notified. But if I wanted to for example response to Ahmed's comment above then I would need to use {at}AhmedIlyas in order for it to show up on his feed. Hope that's clearer.Somewhere
Updated status: I have successfully gone through the initial steps to set the computer up to use WCF and run their samples. After a couple of false starts, I was able to muddle through the process. I tried to create the projects but realized they already existed in the sample folder. Compiled the sample project and tested if it was visible in explorer. It was. So I ran the client app and it did the calculation in the sample program. So thank you for getting me this far. I'll update and call this closed when I can connect across different computers and control the hardware.Infante
progress not perfect. Following Tom's link to create a service definition, I backed out a level and did the "Getting Started Tutorial". This worked well for creating the sample calculator. I learned a lot of basics about how this works. Side note: I did have to change some words around because the program does not work exactly as typedInfante
My problem right now is that if I run GettingStartedHost from inside Visual Studio, it works great. If I try to go into the bin\debug directory and run the exe it does not work. What's the difference. One thing I found very odd was that the DLL was in the same directory as the executable but the config file for the DLL was not. How is that possible. Any insight into why it works great from in VS but not when run from a command prompt in the bin\debug directory would be appreciated.Infante
I am also confused by why the client config file endpoint and the library config file base address are the same but the host base address is different. It also seems I can use either base address in internet explorer and it will bring up the service interface. I still seem to have some learning to do. If I do run the executable from the cmd prompt, I can see it in IE if I use the base address in host program.cs but don't know how to call it from the client. I'm kinda doing hit or miss trial and error but would much prefer to truly understand how these pieces are fitting together (or not).Infante
@DaveB you probably need to post these new queries you have as one or more new questions, as they are implementation details and therefore unrelated to the original question which was more around general approach. If you do that and let me know via comment then I'll do my best to address them there. (remember to use the (at)name thing otherwise it doesn't get sent to my notifications)Somewhere
I agree Tom. You have helped me considerably. I had to destroy the notion that WCF was similar to remoting. It is a completely different way of thinking. I have learned enough to understand the basics of WCF and I am now onto implementation issues. I need to better educate myself over the next week or so before asking more questions. I will post a new question and link you to it if I need additional help. Thanks again.Infante

© 2022 - 2024 — McMap. All rights reserved.