We recvently diagnosed an issue with an existing application that used
remoting and had issues with VPN users as the callback IP address to the
client was not always accurate.

This application was then changed such that now it only uses the Singleton
model.

However, an issue has surfaced where VPN users, if the incorrect IP address
is passed, cause a de-serialization exception on the server for the object
that is passed in to the remot method. If we override and pass in the correct
IP address (where the client can be called back) then the object is
de-serialized just fine.

Any ideas on this? We expected the issue to go away since the Singleton
model would simply open a connection and synchronously wait for the result
over that same connection...

I was going to submit a similar problem.
I have a similar service that has a singleton object that calls back to
clients.
Everything works fine in a LAN. Not so with VPN.

If the client application resides on the VPN initiated machine, then the
connection fails.
If the server application resides on the VPN intiated machine, then the
connection succeeds.

My server and client programmatically setup the channels, etc.
I can't figure out how to set the customErrors mode="Off" in my
application's config file to get more debugging info.

But I do see, by my logging, that the client does get through to the server,
but when the server accesses the passed in object it eventually
exceptions -- like it can't call back to the client.

Perhaps we have the same issue.

~kim



"lex3001" <lex3001 (AT) discussions (DOT) microsoft.com> wrote

I did some research on the web and found others with the same problem.

One solution: specify the VPN Client IP Address in the "machineName"
attribute of the channel.
The example provided by the web page:

IDictionary dctFormatterProperties = new Hashtable();
dctFormatterProperties["typeFilterLevel"] = "Full";
BinaryServerFormatterSinkProvider bsfsp =
new BinaryServerFormatterSinkProvider(dctFormatterProp erties,
null);
IDictionary dctChannelProperties = new Hashtable();
dctChannelProperties["port"] = [the port that you want to
connect to the server on];
dctChannelProperties["machineName"] = [your VPN IP address];
m_chan = new TcpChannel(dctChannelProperties, null, bsfsp);

I tried this and it does work.

~kim


"Kim" <chummers (AT) nospam (DOT) nospam> wrote

That's exactly what we wanted to avoid by using a Singleton -- no reason for
the server to have to call back to the client in a separate connection. (Our
original project used asynchronous callbacks and we did this IP address thing
but then decided to change it a bit and use Singleton instead). After some
work, we discovered our issue went away when we changed what classes we were
passing as parameters into the remote method... odd...

"Kim" wrote: