Problem: Could not connect to registration server. Message reads : An address incompatible with the requested protocol was used

Jun 20, 2008 at 10:12 PM

Hi,

I am seeking suggestions from anybody who can help -- I wonder what else to try to fix this initialization error in my application.  This is the first attempted execution of my MPAPI application.  My line of code is unable to register a distributed node to the RegistrationServer.Exe which is definitely already running in another shell window.

node.OpenDistributed<
CameraTask>(regServerAddress, regServerPort, port);

 

I checked all the IP addresses and ports for correctness. It all seems OK.

The log file seems OK too.  For now, everything is running locally on my host 192.168.1.100, which I verified using IPCONFIG.EXE.   The registration server is configured to use port 8000 as I have verified in its config file.  My log file says:

16:47:50:143 | Info      | Port:8001
16:47:50:143 | Info      | RegistrationServerAddress:192.168.1.100
16:47:50:143 | Info      | RegistrationServerPort:8000
16:47:50:363 | Error     | Could not connect to registration server. Message reads : An address incompatible with the requested protocol was used
16:47:50:393 | Info      | AnalyzerTask online (Worker.ID 0).

The error message seems to be coming from the .NET framework rather than the MPAPI layer.  There is some explanation at the following URL, which suggests TCP6 versus TCP4 issues.
http://blogs.msdn.com/wndp/archive/2006/10/24/creating-ip-agnostic-applications-part-2-dual-mode-sockets.aspx

My ethernet network interface is using TCP4 which I have verified in Control Panel | Network Connections | Local Area Connection because "unchecked" is the state of "Microsoft TCP/IP version 6".  My bluetooth network interface was using TCP6 to my surprise so I shut that off and then rebooted the computer.  It did not fix the problem unfortunately.

Other network applications work OK on this computer (Internet Explorer, various IM, etc.).

Some other source of information suggested another possibility is the firewall but I am not running a firewall software on this computer (I have a hardware firewall on my network.)

Instead of IP address dotted-quad, I also tried to use the host name (my host is ALPEDUEZ) in the config file but that did not fix it either.

By the way my application uses camera vision (to measure traffic speeds of vehicles as they drive by using an ordinary web cam, and alert users about which ones are speeding by too fast. The application is already working in a design using conventional multithreaded techniques for coordinating the camera operations, the disk operations, the analysis engine, the GUI, and so on.  My goal is to obtain parallelism and also some distributed operation by using message passing architecture and a componentized task model rather than a monolithic process.  I want to get away from using conventional multithreaded application code in this application, as well as in all other applications I write going forward if this experiment works out well.  The CPU is pegged at 100% on my computer frequently (a 1.4GHz AMD, at 7 years, a little old for this kind of work) while this application runs due to the near-real time processing load requirements of the system especially when disk operations are needed.  I hope to use MPAPI as the basis for distributing most of the components of my application to a different computer so that my camera worker is the only task handled on my workstation host, thereby alleviating some load on it.  This distributed design is hoped to lighten the CPU load on my camera host, and enable the camera host to be freed up for other things (like Visual Studio 2005) while the application continues to runs continuously in the background.  The other computer(s) on this network can do the rest of the heavy tasks like image analysis, photo retouching, saving photo frames to disk, encoding into motion video, uploading, and so on. 

If this application works out to my satisfaction then I may then feel comfortable recommending and building distributed and parallel systems using MPAPI for my business clientele going forward.

MPAPI seems easier to use than MPI for example, while achieving the same essential goals.  I noticed MPI-2 frameworks (such as provided for free download by Livermore National Laboratory, as well as for $$ as provided by Microsoft on the 2008 Server) have some collective operations like scatter and gather, which MPAPI does not offer, but I don't necessarily need collective operations quite yet.  I am OK to have my application communicate with just one task at a time for now especially since I don't have a very large cluster available for now.  The logical smallness of the application interface to the MPAPI framework makes MPAPI more friendly to begin with this style of message passing parallel programming than those other, older, bigger MPI frameworks.  MPI has a C and Fortran interface, but not a .NET layer, and it is not OOP either, and I don't feel like spending the time designing an OOP-y C# interface myself to that other library at the same time I am learning message passing application development.  That would be far too much difficulty at this early stage.

Thanks for reading,

Geoffrey
Jun 20, 2008 at 10:25 PM
The distributed sample EXE that comes with MPAPI suffers the same registration problem on my host.  The RegistrationServer.EXE is already running for sure.  The correct IP address of my host is already in the config file of the sample EXE for sure, so IP address configuration is not the issue.

C:\Program Files\MPAPI\MPAPI_1.1_Example_src\bin>DistributedPrimeCalculatorApp.exe
[m]aster or [s]lave > s
This nodes port number > 8001
18:21:41:270 | Error     | Could not connect to registration server. Message reads : An address incompatible with the re
quested protocol was used

 

 





mrcoder wrote:

Hi,

I am seeking suggestions from anybody who can help -- I wonder what else to try to fix this initialization error in my application.  This is the first attempted execution of my MPAPI application.  My line of code is unable to register a distributed node to the RegistrationServer.Exe which is definitely already running in another shell window.

node.OpenDistributed<
CameraTask>(regServerAddress, regServerPort, port);

Coordinator
Jun 22, 2008 at 12:47 PM
Hi Geoffrey

It sounds interesting what you are trying to build with MPAPI. I am sorry, though, that you have had some problems with getting it to work. As far as I can tell your problem is exactly an IPv 4 versus v 6 problem. I have just released a new version that uses RemotingLite v.1.2.4 where I force an IPv4 connection. You can either download RemotingLite alone, or v.1.1.1 of MPAPI, which also contains a few performance improvements.

If you have any other problems don't hesitate to write to me! I am sorry that I have not had the time to update the source until now, but I have been busy.

Best regards
Frank

mrcoder wrote:

Hi,

I am seeking suggestions from anybody who can help -- I wonder what else to try to fix this initialization error in my application.  This is the first attempted execution of my MPAPI application.  My line of code is unable to register a distributed node to the RegistrationServer.Exe which is definitely already running in another shell window.

node.OpenDistributed<
CameraTask>(regServerAddress, regServerPort, port);

 

I checked all the IP addresses and ports for correctness. It all seems OK.

The log file seems OK too.  For now, everything is running locally on my host 192.168.1.100, which I verified using IPCONFIG.EXE.   The registration server is configured to use port 8000 as I have verified in its config file.  My log file says:

16:47:50:143 | Info      | Port:8001
16:47:50:143 | Info      | RegistrationServerAddress:192.168.1.100
16:47:50:143 | Info      | RegistrationServerPort:8000
16:47:50:363 | Error     | Could not connect to registration server. Message reads : An address incompatible with the requested protocol was used
16:47:50:393 | Info      | AnalyzerTask online (Worker.ID 0).

The error message seems to be coming from the .NET framework rather than the MPAPI layer.  There is some explanation at the following URL, which suggests TCP6 versus TCP4 issues.
http://blogs.msdn.com/wndp/archive/2006/10/24/creating-ip-agnostic-applications-part-2-dual-mode-sockets.aspx

My ethernet network interface is using TCP4 which I have verified in Control Panel | Network Connections | Local Area Connection because "unchecked" is the state of "Microsoft TCP/IP version 6".  My bluetooth network interface was using TCP6 to my surprise so I shut that off and then rebooted the computer.  It did not fix the problem unfortunately.

Other network applications work OK on this computer (Internet Explorer, various IM, etc.).

Some other source of information suggested another possibility is the firewall but I am not running a firewall software on this computer (I have a hardware firewall on my network.)

Instead of IP address dotted-quad, I also tried to use the host name (my host is ALPEDUEZ) in the config file but that did not fix it either.

By the way my application uses camera vision (to measure traffic speeds of vehicles as they drive by using an ordinary web cam, and alert users about which ones are speeding by too fast. The application is already working in a design using conventional multithreaded techniques for coordinating the camera operations, the disk operations, the analysis engine, the GUI, and so on.  My goal is to obtain parallelism and also some distributed operation by using message passing architecture and a componentized task model rather than a monolithic process.  I want to get away from using conventional multithreaded application code in this application, as well as in all other applications I write going forward if this experiment works out well.  The CPU is pegged at 100% on my computer frequently (a 1.4GHz AMD, at 7 years, a little old for this kind of work) while this application runs due to the near-real time processing load requirements of the system especially when disk operations are needed.  I hope to use MPAPI as the basis for distributing most of the components of my application to a different computer so that my camera worker is the only task handled on my workstation host, thereby alleviating some load on it.  This distributed design is hoped to lighten the CPU load on my camera host, and enable the camera host to be freed up for other things (like Visual Studio 2005) while the application continues to runs continuously in the background.  The other computer(s) on this network can do the rest of the heavy tasks like image analysis, photo retouching, saving photo frames to disk, encoding into motion video, uploading, and so on. 

If this application works out to my satisfaction then I may then feel comfortable recommending and building distributed and parallel systems using MPAPI for my business clientele going forward.

MPAPI seems easier to use than MPI for example, while achieving the same essential goals.  I noticed MPI-2 frameworks (such as provided for free download by Livermore National Laboratory, as well as for $$ as provided by Microsoft on the 2008 Server) have some collective operations like scatter and gather, which MPAPI does not offer, but I don't necessarily need collective operations quite yet.  I am OK to have my application communicate with just one task at a time for now especially since I don't have a very large cluster available for now.  The logical smallness of the application interface to the MPAPI framework makes MPAPI more friendly to begin with this style of message passing parallel programming than those other, older, bigger MPI frameworks.  MPI has a C and Fortran interface, but not a .NET layer, and it is not OOP either, and I don't feel like spending the time designing an OOP-y C# interface myself to that other library at the same time I am learning message passing application development.  That would be far too much difficulty at this early stage.

Thanks for reading,

Geoffrey


Jul 11, 2008 at 2:20 PM
 As far as I can tell your problem is exactly an IPv 4 versus v 6 problem. I have just released a new version that uses RemotingLite v.1.2.4 where I force an IPv4 connection. You can either download RemotingLite alone, or v.1.1.1 of MPAPI, which also contains a few performance improvements.
Yes I agree you are probably correct about IPv6 being the difficulty. I am about to download and use the newest versions of your libraries and I will verify it soon.  I am optimistic.

What still confuses me, is that I recently disabled IPv6 from my Windows XP.  However, I still have the problem which I reported.  Removing IPv6 from Windows XP is more difficult than I expected!  Apparently, I only partially disabled IPv6 on my host.   I really dont need to keep IPv6 running for anything at all at least for now, so I don't mind turning off IPv6 to help MPAPI.  It is a good idea generally to remove unnecessary processes from computer memory in my opinion.  

The obvious way to disable IPv6 turned out to be insufficient -- here is what I tried:

Control Panel | Network Connections | Local Area Connection | Properties | Microsoft TCP/IP version 6 | un-check the checkbox | reboot the computer.

The above doesn't actually remove IPv6 completely from working memory.  If anybody knows the rest of the necessary steps, it would be nice to know what other steps are needed to disable IPv6 on Windows XP just for the knowledge of how to do so.

Thanks for reading.  And also thanks for the advice and the new software revisions.

Geoffrey
Jul 11, 2008 at 5:36 PM

Hi,

I still have the same basic connectivity errors on my Windows XP host unfortunately after the update to latest versions.  Maybe my OS needs to be wiped off and reinstalled? uggg... 

Anyway, here is what displays when I use the new versions of your software.   I have carefully removed the old version of all the MPAPI software and dependencies into a hidden directory to prevent confusion about versions with the new one.  I have freshly recompiled all your code from source.

This is RemotingLiteExampleServer:

C:\Program Files\MPAPI\RemotingLite_1.2.4_example\RemotingLiteExampleServer\bin\Debug>RemotingLiteExampleServer.exe
Host is running. Press <ENTER> to terminate.
Address is ::1
Press <ENTER> to terminate.

That's a funny address.  I think it's IPv6 unfortunately.  Vista is not my OS. 

What address do other people see displayed when you run this program on XP?


And here is what displays in the console when I run the client example program:

C:\Program Files\MPAPI\RemotingLite_1.2.4_example\RemotingLiteExampleClient\bin\Debug>RemotingLiteExampleClient.exe
Using our own implementation that inherits from ClientBase<>

Unhandled Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocati
on. ---> System.Net.Sockets.SocketException: An address incompatible with the requested protocol was used
   at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
   at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
   at System.Net.Sockets.TcpClient.Connect(IPEndPoint remoteEP)
   at RemotingLite.Channel..ctor(IPEndPoint endpoint)
   at IServiceProxy..ctor(IPEndPoint )
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle._InvokeConstructor(Object[] args, SignatureStruct& signature, IntPtr declaringType)
   at System.RuntimeMethodHandle.InvokeConstructor(Object[] args, SignatureStruct signature, RuntimeTypeHandle declaring
Type)
   at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, Cultu
reInfo culture)
   at RemotingLite.ProxyFactory.CreateProxy[TInterface](IPEndPoint endpoint)
   at RemotingLite.ClientBase`1..ctor(IPEndPoint endpoint)
   at RemotingLiteExampleClient.ClientProxyImpl..ctor(IPEndPoint endpoint) in C:\Program Files\MPAPI\RemotingLite_1.2.4_
example\RemotingLiteExampleClient\ClientProxyImpl.cs:line 26
   at RemotingLiteExampleClient.ExampleUsingClientProxyImpl.Start() in C:\Program Files\MPAPI\RemotingLite_1.2.4_example
\RemotingLiteExampleClient\ExampleUsingClientProxyImpl.cs:line 23
   at RemotingLiteExampleClient.Program.Main(String[] args) in C:\Program Files\MPAPI\RemotingLite_1.2.4_example\Remotin
gLiteExampleClient\Program.cs:line 13

C:\Program Files\MPAPI\RemotingLite_1.2.4_example\RemotingLiteExampleClient\bin\Debug>

 
The  "incompatible address" error is still breaking my RemotingLite and therefore my MPAPI installation. 

I won't even bother to try the demonstration programs for MPAPI since they depend on RemotingLite working correctly.

It would be a big waste of time to erase my system disk and install a whole new OS.  Therefore I hope to find a way to fix my OS installation more quickly if that's really the problem here.  It is starting to seem that maybe it's my OS because since nobody else is reporting these problems with RemotingLite on XP. 

With luck, I might find that there is way to completely disable IPv6 from WindowsXP.

I am going to borrow someone else's XP computer.  Today I found someone who can let me try RemotingLite on their computer.   

If RemotingLite demos run OK on their computer then I guess I will know it's time to discard my XP Workstation installation into a garbage dumpster.  I have had problems in the past with COM services on my computer, so my working theory is that my COM services are partially broken, and remoting is broken too as a result.  It's a shame because this computer's OS installation is only 1 year old.  I've never had a Windows installation or registry go bad so quickly before.


Thanks for reading.

Geoffrey

Jul 11, 2008 at 6:06 PM
On my friend's XP Workstation the example programs for RemotingLite both work perfectly.  Your code is good Frank.

I guess that means my own XP installation on my own computer is garbage perhaps.

My friend's XP has strictly IPv4 installed, as confirmed by Control Panel | Network | Local Area Network Connection 1 | TCP/IP | Properties, and also by IPCONFIG.EXE executed in a command shell.  There is no sign of any IPv6 capability on this computer.  I wish I could get mine to be this way too. 

I really dont know how IPv6 got onto my computer because I certainly dislike what it does to .NET 2.0 in my experience!!

I would like to know if other people's experience also indicates problems, or not, with IPv6 and .NET 2.0 both on the same Windows XP box.