I am a newbie in remoting concepts(C# Remoting).Actually i done some projects using
remoting concepts, i need to employ a proxy between the client and server , if client
wants to communicate with the server or vice-versa it should be done through this proxy
only.i saw a namespace Remoting.Proxy ,will it help? anyone giveme some suggestions on
how to do this it will be very useful for me.
I heard that if the request is through proxy it will be more secure.if my server address is(182.575.069.67) and my proxy runs in 192.168.0.8 then all my clients must send their messages to the proxy and the proxy server must forward this to the actual server.This is what i am trying to do
The "Proxy" namespace refers to the idea that there needs to be a local object, working en-proxy for the remoting client.
If you need all traffic to the server to go through a proxy, you should create two executables: the server, and the proxy server.
The server could accept requests only from the proxy service, while the proxy service itself could be promiscuous.
However, I'm not sure why you would need to set up a proxy service, since you should be able to put any of your autorization / authentication code directly into the server service anyways.
Proxies in C# (especially in the System.Remoting namespace) are local, in-process objects that represent an object in a different process.
They're named after the Proxy Object pattern, not after proxy servers.
Related
I am using WCF with duplex netTcpBinding and I want to send a message to all users connected currently to my service. I thought I could just create a callback contract and it would send a message to all the clients but it seems I am mistaken, and there isn't a single server/service, each client gets its own service?
I have service with the name 'Server'. Here is how I access the server from the client -
ServerClient client = new ServerClient();
string result = client.SendMessage(messageTextBox.Text);
client.Close();
I thought the 'Server' was a single object that handled all calls by my clients but then I've started a thread in the Server constructor and I found out that multiple threads get started because every time a client calls the Server, a new Server object is created.
So it seems each client has it's own service/server.
With that in mind how do I send a message to all my clients from the server?
I thought the standard practise for accessing the server from the client was to get a proxy object, call the service functions, and then Close the proxy object like in the code above...but if I close the proxy object doesn't it mean I have closed the connection between client and server and now the server won't be able to make duplex callbacks to the client?
1) If you want all clients to share the same server, you need to make your service a singleton. Add this attribute to the class implementing your service (not the interface):
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)]
That said, I suspect that what you really want is a synchronized, static (thread-shared) instance of a List<ServerClient>. Then you would iterate over that to send a message to each client. With that design, you wouldn't need a singleton server (just some good thread safety around the list).
2) If the clients close their server proxies, the server will not be able to send them any messages. You need to keep the proxy open and stash them somewhere in the client. This design will of course significantly limit scalability.
By default each client will get its own instance of the service. You can however make your service a singleton (which will than process requests from all client).
You may also want to skim through this Instance management article
After looking into WCF, I don't believe it can do what I need it to. What would be the appropriate way (if I have a server and client application, both C# .NET Console apps) to basically instruct the client to execute functions?
For example, if the client application has functions such as DownloadFTPFile(), CreateWindowsService(), IsServiceRunning(), etc. what would be the standard approach to telling them to execute this from the client?
I was initially just going to have the client interpret messages sent from the server, such as "downloadfile ftp://filename.zip" but I am wondering if there is a better way.
Client has Agent.
Agent connects to server, polls for cmomands
Agend executes comands.
THe server sending is tricky unless you control the environment. NAT for example makes "client sends" a nightmare. You also then open up the client for additional attacks with client polling the clietn firewall does not have tp open external access to the agent.
It is possible.
Use the callback functions along with duplexes in the WCF. You will be limited to the intranet usage or azure though, since only NetTcpBinding and NetTcpRelayBinding support it (WsHttpBinding is deprecated).
With WCF, any client can self-host a WCF service. This can make the client be a service. Add a little extra protocol between the client and the service, and you've got your wish.
My Intranet users are accessing the Internet through a proxy on the network. I need to monitor and filter certain requests to that proxy on a few machines. In essence, I need to proxy the proxy on the local machine.
How do I insert a local application as a relay between the local system and the Intranet proxy?
I would have to change the local proxy settings to an endpoint on the local machine, which in turn should relay HTTP requests to the outside proxy. But, I have no experience with writing proxies. Is this even possible?
Edit: The term I was looking for is tunneling, not proxying through a proxy. It is possible and I managed it with a TCP pipe.
Why not use an existing proxy server? This has all required capabilities and you don't have to worry about stability and performance.
I wrote a custom TCP tunnel that forwards requests to the Intranet proxy and pointed the browser proxy to the local machine.
I have a WCF webservice that acts as a proxy between a WCF windows service and a client interface. This is done so that our program can have a central "state" server, while the webservices can be distributed.
Ideally i would like to cut out the middle IIS hosted WCF webservice serialization and feed the bytes sent by the client directly to the windows service via IIS. Is this possible?
Why not using NLB directly? I think that a cluster will do a better job distributing requests than a proxy WCF service.
It's possible but you'll want to not use WCF in the middle. The level of difficulty depends on the technology you're using for your transport. For example, if you're using BasicHttp (good ol' SOAP) you can write a proxy in ASP.NET that routes the bytes from the client to the server via an HttpWebRequest.
You also could consider installing a reverse proxy on your web boxes to route your WCF requests through to your central web service.
Simple issue. I'm working on a proof-of-concept for an application with additional database connection, so I will create a WCF service to wrap around the database. Multi-user environments will get this service installed on a centralized server with a client application on their local system. These users will automatically have to deal with firewall issues, so this is acceptable.
But the single-user environments will have the service and client application running on a single system. The service host doesn't have a definite shape right now, but it's likely that it will be hosted within the application itself or as a Windows service.
Unfortunately, the client application is a WIN32 Delphi application which needs a simple way to access the service. Preferably, the single-user version should use the same technique to access the server as the multi-user version, which means that it behaves like a SOAP client, with a WSDL imported and converted to Delphi code.
Still not a problem, but I have to consider possible problems that we can encounter in this setup, with the most important issue: possible firewall that closed the connection port.
So, does anyone know about any firewall problems that can occur in this single-user environment?
You haven't mentioned which WCF channel you're using- I'll assume basicHttpBinding. Generally, if your local service is bound to 127.0.0.1 using self-hosting, and the on-box client accesses it that way, you should be fine. No firewalls I'm aware of will screw with your loopback adapter. If you bind the service to the machine's IP though, you may subject yourself to firewall fun.
If you have WCF 3.5 available on the client on both ends (sorry, I don't know anything about Delphi), have a go with netNamedPipeBinding.
You didn't mention which version of Delphi you use but I once had hard time making Delphi 2005 import a WCF service with basicHttpBinding. As the WSDL is split among many pages, the SOAP import wizard in Delphi wasn't capable of understanding it. I finally ended up writing an ASMX wrapper around the WCF service for Delphi clients.