IPCSocket - NameResolutionError

I am working on a multiple IPCSocket need for multiple Console Applications. This has been working for a while but not as good as I wanted it to. Basically if one side did not participate then the whole communication scheme to the other Console Applications did not work as well. So I am back at taking a look at improving this IPCSocket scheme and have now ran across a consistent NameResolutionError - 103. I have looked at the manual examples which are ok in a static sense - I am looking to programmatically do this.

The ultimate goal is to have the server boot up and these Console Applications will start whenever they do and enable processing even when one of the Console Apps is not running. There is a ‘main’ console app that controls when an app will run and uses the IPCSocket to perform that communications. The Main app is the Server and it performs the Connects. The other apps Listen. The IPCSocket - on Listener side is mySocket - and on the Connect-Server-Main side it is mySocket(x)

Using this statement in the Initialize step mySocket.Path = SpecialFolder.Temporary.Child(myIPCSocket_folder1).NativePath
and then have the String variable myIPCSocket_folder1 set to com.myapp.myIPCpath1 (The 1 is replaced by 2, 3, 4… as needed) this makes sure the Server and Listener point to the same Temporary folder locations. Yes this is the same server, same User where the Console Apps are running.

I can absolutely identify that the paths are correct when an error occurs. I post to Console Log in separate folders for all Console Apps and the Connect and Listen paths are the same. Here is the path that both have

I can usually resolve this by rebooting the server. However that is not preferable. How can this be resolved? How do I synch both the Server and Listener when these errors occur? Who starts the 'recovery process? Server - Listener?

If there is a good primer on IPC Sockets please advise

Thanks

I think you get a name resolution error when you call connect and there’s no listener on the path.

Exactly what I was looking for. The Listener goes first. I have even set the folder to another path. When the Listener goes first is it normal to get 103 on the Listener as you attempt to connect? No Server is running at this time.

This is code that was working. After several changes in code and running in debugger on same machine the IPC aspect seems to be failing. I might just reboot and see what happens but still I would like to find out why and what

Thought I found something in what I just mentioned - a Listener does not do .Connect it .Listen so thats not it.

I have placed IPCSocket.Listen in a timer so the socket has time to finish what it is doing first. Prior to that I was seeing frequent Error 103.

Just to clarify:

  • Server = Listen
  • Client = Connect
  • IPCSockets only support one client at a time.
  • make sure you stop listening by calling Close when you are done. If you don’t, the next instance of the server app will not be able to listen on that path.

@Richard Corlett - just exactly how did you construct [quote]I have placed IPCSocket.Listen in a timer so the socket has time to finish what it is doing first. Prior to that I was seeing frequent Error 103.[/quote]

I just cannot seem to stop 103 errors from happening

Xojo’s IPCSocket can be a little bit cranky.

As Greg says, Error 103 occurs when trying to connect while the other side is not listening. After an Error 103 you need to call IPCSocket.Close then IPCSocket.Listen, but I also found it was necessary first to re-instantiate the socket and set the path again.

When I had this recurring issue I set up logging on both sides of the socket with a milliseconds recorder and writing out to a file. I was then able to figure out exactly where things were getting out of sync.

From your description, your usage situation is a little different from mine. I have a desktop app that launches the service app from a shell and the desktop app then sends commands to it through an IPCSocket. The service application uses the Print method to send responses back to the desktop side through the shell.

Would it not be sound to have one app centralise calls through a ServerSocket, and transact through HTTP ?

Or use autodiscovery to find an existing group and if it doesn’t exist then create the group
Then you know you are the first so you listen and everyone else connects since they find there is already a group to join

That way the processes basically figure out who the server is and know whether to listen or connect

First I would like to thank everyone for there responses and suggestions. This may have taken a while for me to digest but I think it was worth it.

This may appear to be a long piece. The intention is to provide those participating in this thread the ability to see the solution and comment on it in an effort to make it a better solution. In this community more than once I have received someones solution to certain pieces that opened a door for me and this is my attempt to bring something back in the hopes it will be useful to others.

Background:
For some time I have been looking at various methods to ensure network activities did not over burden the CPU and db data would not be corrupted. There were multiple console applications constantly working in the back ground and at anytime db corruption could occur as well as needed network activity could become sluggish.

I have been looking for a way to ensure data in multiple MySQL db(s) (for that matter it could be any db) was correct at time of need for these autonomous applications that utilized the same shared db tables and that the data was updated properly so when other applications needed it that data could be used to correctly do what was required.

Before solving this I could get full capabilities needed at the price of loading down the CPU with anywhere from 40% to 90% CPU activity per application while those applications were ‘idle’. Having 6 applications needing so much CPU time created a sluggish response. A solution such as Apple MAC Pro 2013 with a minimum of 12Gb worked but if I could find a way to resolve the CPU loading and maintain functionality that would be more desirable for most needs and for the bigger ones I could always grab a MAC Pro.

The time is now:
So I finally came to the place where I needed to focus on this need. Having multiple IPC Sockets working simultaneously seemed to be a solution. These applications perform significant network (TCP, UDP) and db access all the time. Most times these console applications are not doing anything but looking. This is what I refer to as ‘idle’. When looking and the need to perform work occurred ‘active’ CPU activity increases with respect to the ask. This ask comes from other external network applications and devices and could literally occur at anytime.

Need:
So how to reduce CPU loading, improve network activity and ensure db data integrity was the need. The testing I have just completed using IPCSockets has enabled all of that to become true. For sub apps CPU usage is reduced when ‘idle’ which used to require on average 40% to less than 1%. For the Server app CPU usage went from over 90% to less than 6%.

When performing ‘active’ work CPU loading for SubApps has been reduced from over 90% continuous to less than 40% peak on average to less than 6% continuous. For the Server app CPU usage went from over 90% continuous to less than 50% peak and less than 7% continuous.

Due to the nature of controlling external console applications using IPCSockets I also know for certain db activities are not being read or written with ‘old’ data preserving data integrity. No table locking or unlocking etc is required. To me this was a huge benefit of going after an IPCSocket solution.

Lastly since CPU loading is significantly reduced network activity has improved and overall performance as at a minimum shall I say is very snappy. Testing has shown this to be a comparison of a Volkswagen Beetle to a Porsche 911 with the load carrying capacity of a tractor trailer.

Solution:
Do not use something to this affect IPCSocket(x) Append. For a while I had been trying to get this to work. Not until I stepped through a debugger session did I realize this was never going to work. Even though this looks like a way to have discrete IPCSockets ALL paths get set to the one you want to Listen-Connect. As soon as you do this the Connecting application that is not on that path throws a 102, 103, 105 or even 22.

These errors just cascaded themselves until you were completely out of the ball park. In the end for me the key to this was understanding how to create, maintain and perform the needed dance to have Multiple IPC Sockets concurrently working and have the ability to recover when either the Server-Listener went down or anyone of the SubApps-Connector went away maintaining functionality and recovering gracefully.

The key was the Server as this is the most important piece since it collaborates with all the other SubApps.

Oh by the way it did help to read a piece on Unix IPCsockets in Wiki.

In the Server app:
Discrete IPCSockets with specific paths are created
All IPCSockets are set to Listen to the correct path
A Timer works inside the idle loop to check and reset needed IPCSocket ‘Listen’ needs
In the Error Event Handler the correct action is taken when a disconnect occurs

In the SubApps:
Discrete IPCSockets with specific paths are created
All IPCSockets are set to Listen to the correct path
A Timer works inside the idle loop to check and rest needed IPCSocket ‘Listen’ needs
In the Error Event Handler the correct action is taken when a disconnect occurs

This is what I refer to as the dance and when you get it right good stuff happens. Sometimes wisdom creeps in slowly.

I include a link to my DropBox where 6 XOJO Console apps exist. One Server and 5 SubApps. The solutions write to their respective Console folder as follows:

[quote]Server - /Users/UserName/Library/Logs/IPCSocket_TEST/Server
SubApp1 - /Users/UserName/Library/Logs/IPCSocket_TEST/ipcs1
SubApp2 - /Users/UserName/Library/Logs/IPCSocket_TEST/ipcs2
SubApp3 - /Users/UserName/Library/Logs/IPCSocket_TEST/ipcs3
SubApp4 - /Users/UserName/Library/Logs/IPCSocket_TEST/ipcs4
SubApp5 - /Users/UserName/Library/Logs/IPCSocket_TEST/ipcs5[/quote]

This is how you can observe connectivity between each other. DO NOT leave these console apps running for too long as I did not implement control for file size. The log files will simply continue to grow if you leave them running. Once I came upon this solution I did not spend time resolving the data passing in these test apps. I did that in my realtime apps but you can see the beginning of how It was implemented.

This link Console Folder will take you to my Dropbox. Inside the Console Folder you will find the 6 apps needed to use and test

I hope this will be beneficial for someone who finds and joins this thread

Comments and suggestions welcomed

UPDATE:

In this text
In the SubApps:
Discrete IPCSockets with specific paths are created
All IPCSockets are set to Listen to the correct path
A Timer works inside the idle loop to check and rest needed IPCSocket ‘Listen’ needs

This update is needed
In the SubApps:
Discrete IPCSockets with specific paths are created
All IPCSockets are set to Listen to the correct path
A Timer works inside the idle loop to check and rest needed IPCSocket ‘Connect’ needs