This project is read-only.
1
Vote

CommunicationError with WinCE 6.0 Device

description

I have run into a strange issue when using XcoAppSpace v1.4. I am running a XCoordination worker on a remote PC under the full .NET framework and I am attempting to connect to this worker using my WinCE device.

I have added a button to the WinCE WinForm app that attempts to connect to the remote worker using TCP for the transport and JSON for the serializer. However, every time I try to connect using this button I receive a socket error (error #10060 - connection timeout) then a XcoCommunicationException which states that there was a communication error.

The strange thing is that I can successfully connect to the remote worker if I attempt the connection within a locally hosted worker (on the WinCE device) that is invoked via a connection from the remote PC. The only difference that I can see in these two scenarios is that the scenario that fails is running in the WinForms thread context and the scenario that succeeds is running the the WinCE hosted worker context.

Any help with this would be greatly appreciated!

file attachments

comments

husterk wrote Jul 15, 2013 at 6:47 PM

Update: Further investigation shows that I can successfully connect to the remote worker from the WinCE device as long as the local WinCE worker has been instantiated (by making a remote connection from the server application). I have commented out all of the functionality of the worker but left the empty port handlers in place. Once any one of the handlers has been executed my button on the WinForms app now successfully allows me to connect to the remote worker on the PC. It seems like something in the compact framework version of the XcoAppSpace class is not being initialized / instantiated properly till a first worker has been created and instantiated.

husterk wrote Jul 16, 2013 at 5:46 PM

UPDATE: It turns out that the issue was caused by having multiple NICs on the Windows CE device. It looks like XCoordination is not properly selecting the appropriate NIC for communications. In our scenario, we have one real NIC (wired Ethernet interface) and one USB debug interface that resolves as a NIC on the device due to the Windows Mobile Device Center connection used for debugging. For some reason, the NIC selection is changed when a connection has been made to the device from the server. However, the problem described above is resolved just by unplugging the USB connection.

Is there any way to specify which NIC XCoordination should be using?

thomass wrote Jul 17, 2013 at 7:36 AM

Hi Keith,
Happy to hear that you already found the cause of the problem. There is a way to specify which local IP adress should be used, maybe it helps in your case (I have used it on servers that have multiple networks / IP adresses, but never on a mobile device):
var tcpTransport = new XcoTCPTransportService("localIP", 8000);
space = XcoAppSpace.Configure
    .UsingService(tcpTransport)
    .Create();
Could you try this out and tell me if it helps.

husterk wrote Jul 17, 2013 at 1:01 PM

@thomass - I think we are already doing this (see my current space configuration and connection attempt code below). Please note that the MobileConfigManager class is just a simple class I created to emulate support for an App.config file in .NET CF. Also, the "LocalIpAddress" field is specified as an actual IP address (i.e. 192.168.10.100) which corresponds with the intended real network interface.

Space Configuration

_Space = XcoAppSpace.Configure
            .UsingService(new XcoTCPTransportService(MobileConfigManager.Settings["LocalIpAddress"],
            Int32.Parse(MobileConfigManager.Settings["LocalSpacePortNumber"])))
            .UsingService<XcoJsonSerializer>()
            .AsDefault()
            .Create();

Connection Attempt

String ipAddress = MobileConfigManager.Settings["RemoteServerIpAddress"];
String portNumber = MobileConfigManager.Settings["RemoteServerSpacePortNumber"];
// Connect to the FieldUpdateProgressWorker to prepare to send progress updates.
_FieldUpdateProgressContract = _Space.ConnectWorker<FieldUpdateProgressContract>(
                    String.Format("{0}:{1}/FieldUpdateProgressWorker",
                    ipAddress,
                    portNumber));

thomass wrote Jul 17, 2013 at 5:21 PM

Hi Keith,
Hmm yes what you are doing looks correct. In this case the TcpListener is initialized with the defined IP adress instead of "IPAdresse.Any" which I assumed could have caused the problem.
After again reading your description I understand that when you want to establish the connection from mobile device to server first, then it doesnt work. But it works when you establish it first from server to mobile device. If that is the case - then this would mean that not the TcpListener has a problem, but creating the TcpClient doesn't work as expected.
Maybe defining the TcpClient's local IP endpoint could help - I will do the necessary adaptations as soon as I find the time and provide you a version for testing.

husterk wrote Jul 18, 2013 at 1:29 PM

@thomass - Yes, the issue is with creating a TcpClient on the mobile device and attempting to connect to a remote TcpListener on the PC. I agree with your analysis that defining the TcpClient's local IP endpoint should help resolve this issue (this should help to force the underlying socket to bind to the appropriate NIC). Also, my original description of "when you want to establish the connection from mobile device to server first, then it doesnt work. But it works when you establish it first from server to mobile device." was not quite correct. The connection from the mobile device to the server seems to be luck of the draw as to which NIC is selected when the TcpClient is created on the mobile device.

wrote Jul 18, 2013 at 3:05 PM

thomass wrote Jul 18, 2013 at 3:06 PM

Hi Keith,
Please try out the attached version, it now uses the same local IP adress as the TcpListener for connecting.

husterk wrote Jul 18, 2013 at 5:53 PM

@thomass - No luck... I tried the new DLL and it didn't seem to impact the client connection attempt. I will keep digging around to see if I can find out more info on this issue.

husterk wrote Jul 18, 2013 at 6:39 PM

@thomass - FYI... I found a workaround that seems to be working reliably. On the WinCE devic, instead of specifying remote server IP address I specified the remote server name and allowed the .NET CF to resolve the IP which seems to have forced the created TcpClient to utilize the correct network adapter. I am still not sure why the .NET CF is not selecting the correct adapter when an IP address is specified but at least we have a workaround for now.

thomass wrote Jul 19, 2013 at 6:32 AM

Hi Keith,
I did some more tests to ensure that the TcpClient Socket is really bound to the specified IP address, which really seems to be the case - strange that it doesn't help. But I'm glad that you at least found a workaround. Let me know when you find out anything that could help resolve the issue.