I am attempting to set up a IPCSocket to communicate with a database application. The code I am using is:
listbox1.addrow "Connect Clicked " -debug code
Dim IPCFolder as New FolderItem
IPCFolder = Volume(0).Child(“XOJO”).Child(“commFile”)
IPCRequest.Path = IPCFolder.NativePath
ListBox1.addrow "native path " + IPCFolder.NativePath -debug code
DIM s As BinaryStream -debug code
s = BinaryStream.Open(IPCFolder) -debug code
ListBox1.AddRow "HERE IT IS " + s.Read(s.length) -debug code
IPCRequest.Connect
When I run this method, it tells me that the path to the IPC file is C:\XOJO\commFile which is a physical file on my computer. It exists and is correct. I can read the file as a binary stream OK but when I get to the IPCRequest.Connect the IPCSocket throws an error code of 103 NameResolutionError.
IPCSocket paths are something of a mystery to me - I’ve always treated them not as actual files, but as virtual ones.
I’ve been using this code for years, and it seems to work well on Mac OS X and Windows:
mySocket.Path = "/tmp/myCompanyName/myAppName"
Strangely, how I’ve been doing it for years does not seem to match what you are doing (which seems to be how the LR claims it should be done). I don’t know what the right answer is…
While there might be a file involved you wont be able to read & write the file using an IPCSocket on Windows
IPC Sockets on Windows are special in many respects compared to Linux & OS X
I’m not sure what it is you’re trying to connect TO - it would HAVE to be another IPC Socket and I suspect it will have to be a Xojo app (at least on Windows)
I have a similar problem and cant find a solution.
On Windows, I use a IPCSocket to communicate between two instances of the same application. Basically, if the application is already running (it uses a Mutex) the new instance pass to the running instance a parameter.
It works, for the first time, the first instance Listen on a predefined path and the newly launched application Connect to the same path, pass the required info to the master and then exit.
Trying this a second time, the newly launched instance raises an error 103 and cant connect with the master.
Any ideas?
EDIT:
Ive found that after the first connection/disconnection, I have to reset the socket with Close() and then Listen() again.
This make it functional again.
Sounds like a bug to me, but perhaps is a normal behavior of IPCSocket on Windows.
Massimo I surely don’t have any answers, but I am doing similar work on Mac OS with IPC Sockets communicating to four console applications from my main Desktop app. I am struggling to find a method of troubleshooting for IPC Communications since of course wireshark won’t see anything since IPC on Mac/lInux are UNIX File Handles. I am not seeing the same issue you are, but I am coming across a similar disconnect sequencing issue that in my case is because of my code.
However if we would watch the IPC communication negotiation and socket communication this would help me tremendously. It can’t be as easy as a tail -f on the IPC file … can it? (Sorry for the HiJack Question on Question).
I use IPCSockets on Mac to communicate between multiple applications and had no problems at all.
Perhaps you can set some System.DebugLog messages in the socket events (DataAvailable, Error, Connect) to see what happen on the console.
[quote=47336:@Massimo Valle]
Ive found that after the first connection/disconnection, I have to reset the socket with Close() and then Listen() again.
This make it functional again.
Sounds like a bug to me, but perhaps is a normal behavior of IPCSocket on Windows.[/quote]
Normal - once it has listened & connected a disconnect should make it listen again otherwise there’s nothing listening
Norman, sorry but I don’t see the logic on this.
If A is listening, B connect and then disconnect, why I have reset A with Close+Listen to make C connecting?
[quote=47386:@Massimo Valle]Norman, sorry but I don’t see the logic on this.
If A is listening, B connect and then disconnect, why I have reset A with Close+Listen to make C connecting?[/quote]
I’m not sure if it’s logical, but think this is how they have always worked: you can only Listen/Connect once for a given IPCSocket pair.
[quote=47386:@Massimo Valle]Norman, sorry but I don’t see the logic on this.
If A is listening, B connect and then disconnect, why I have reset A with Close+Listen to make C connecting?[/quote]
That’s true of any socket. Once it connects it is no longer “listening”. After a disconnect, it must be told to listen again. It’s not a ServerSocket, after all.
I send a “STOP” message to terminate a slave consoleapp and got “ACK” message from there. After sending “ACK” message, the consoleapp quits(QUIT(0)).
When I try to start the consoleapp again with the same PATH, the Cosoleapp got 103 error so couldn’t send “ACK” message to a main application.
Of course, I tried to reset the Socket like below.
Can you point me the wrong part?
What can be a workaround?
In DataAvailable Event of Socket subclass.....
Dim i As Integer = InStr(0, me.Lookahead, EndOfLine)
Dim finalPathnumber As String
If i = 0 Then Return
While i > 0
Dim getString As String = me.Read(i + 1)
getString = Left(getString, getString.len - 2)
If Instr(getString, "ACK_FROM_SLAVE") > 0 Then 'Collector is going to be stopped seding this message
'MsgBox "ACK_FROM_SLAVE"
IPCArray(Me.ID).Close
finalPathnumber = str(IPCArray(Me.ID).pGetREP_REPSETCOUNT) + str(IPCArray(Me.ID).pGetREP_INSTANCE_COUNT) + IPCArray(Me.ID).pGetREP_PORT
IPCArray(Me.ID).Path = SpecialFolder.Temporary.Child("com.example.ipcsocketexample").NativePath + finalPathnumber
IPCArray(Me.ID).Listen
IPCArray(Me.ID).Poll
End If
MainWindow.RepConfigurationScreen.TextArea1.AppendText getString
i = InStr(0, me.Lookahead, EndOfLine)
Wend
in addition to calling IPCSocket.close, you should actually Nil the object and then create another one
you may want to try using a new, unique, path name for each socket - don’t re-use the socket IDs. The master app can communicate this ID with the slave app in a few ways, e.g. using a Mutex, or Comannd Line Parameters, or Environment variables, etc.
IPCarray elements are predefined, and I made a property ID then I distinguish IPCSockets with them.
Shall I try to make the PATH name with random values instead of the one used before?
I’m a little bit confused with the way like Mutex, CMD line env.
IPCArray(Me.ID) = nil
IPCArray(Me.ID) = new IPCSocket
...
Yes, using random PATH names may help, but the problem is : how does the client app know what the path name is? Somehow that information needs to be communicated between the server and the client. If, say, you are launching one client per socket, then you can include the socket path in the command line when you launch the socket.
I just generated random number to get the unique PATH name in addition to reset Socket when disconnected and try to reconnect.
I haven’t made IPCArray element Nil though.
It works now.
(Sorry for the HiJack Question on Question).