Proper Path for IPCSocket

  1. ‹ Older
  2. 2 months ago

    Jon O

    Aug 8 Pre-Release Testers, Xojo Pro Chicago Area USA

    @Emile S In a projectnot related to IPCSocket, I was not able to delete a file from the TemporaryFolder (and that file was there, on macOS, cause at reboot time, it was there !). I do not checked the error #.

    But Windows doesn't use the file. No file is ever created if you look in the path. It's because Windows uses a network socket. I remember reading that....

  3. Norman P

    Aug 8 Pre-Release Testers, Xojo Pro great-white-software.com/blog

    should be using a TCP socket bound to the local loopback port

  4. Jon O

    Aug 8 Pre-Release Testers, Xojo Pro Chicago Area USA

    @Norman P should be using a TCP socket bound to the local loopback port

    Is this the recommended way to do it instead of using an IPCSocket? Why should I not be able to use Xojo's built in class?

  5. Norman P

    Aug 8 Pre-Release Testers, Xojo Pro great-white-software.com/blog

    that IS what an IPCSocket on windows already is ... sorry for the lack of clarity

  6. Jon O

    Aug 8 Pre-Release Testers, Xojo Pro Chicago Area USA

    @Norman P that IS what an IPCSocket on windows already is ... sorry for the lack of clarity

    OK. So yeah, it should. I wonder if it's a firewall issue? Something is causing a Name Resolution Error.

  7. Norman P

    Aug 8 Pre-Release Testers, Xojo Pro great-white-software.com/blog

    Could be a firewall blocking it but connecting to the local loopback I thought wasnt supposed to cause that
    Possibly multiple firewalls with different settings ? (Windows + some antivrus one ?)

  8. Massimo V

    Aug 8 Pre-Release Testers, Xojo Pro Europe (Germany, Würzburg)

    You can use whatever you like for path, including a random string. The Windows implementation just translate the string into a port with a known algorithm.
    I use it with UUID for example.

  9. Wayne G

    Aug 9 Pre-Release Testers, Xojo Pro New Zealand axisdirect.nz

    Based on this conversation http://forums.realsoftware.com/viewtopic.php?p=15645 I gave up on using IPC Sockets and use server sockets. This allows me to reject connections from other than 127.0.0.1 (if required) and still be listening and also gives me the ability to communicate with multiple helpers/clients.

  10. Massimo V

    Aug 9 Pre-Release Testers, Xojo Pro Europe (Germany, Würzburg)

    I implemented IPC sockets in a system which uses lot of sockets in a multi user environment and I can say after some initial problems it now works very well and reliably. This is on both Mac and Windows, due we have cross platform system.
    The only problem I found on Windows is that, being this tied to a TCP port you need to consider on opening a new socket if that port is already taken. It would be nice to be able to feed the IPCSocket with the real TCP port to open instead of a string for which you can't predict on which port will be translated.

  11. Jon O

    Aug 9 Pre-Release Testers, Xojo Pro Chicago Area USA

    OK all, I think I figured out the problem and I am not sure if this is new to 2019R1 or not because I haven't seen this before. It's not a Windows problem as I've duplicated this on the Mac. Here's what I do...

    I have two apps. I want those apps to communicate with each other when both are running. The problem is I don't know which app the user started first. I need the first app to be a listener. So when the app starts, it attempt to listen on the IPCSocket. If that works, great. If the app being started is the second app, then when I call ICPSocket.Listen, I get an error 105. Then in the error handler, I have code to reset the socket and call Connect.

    The problem I am seeing is that once this now happens, the socket is FUBAR period. You always end up getting a 103 error whenever you try to connect. It doesn't matter if you quit and restart the app. It's FUBAR.

    I've duplicated this many times using the example applications. I start one of the example apps and click the listen button. I then start the second copy of the example app and click listen. I get an error 105. I then quit that copy. I restart that copy and click connect. I get error 103. I then quit the second app again and try it again - I still get 103. Nothing has thrown an error in the first app so I don't know that I need to reset that socket or do anything. But the socket is completely hosed. Nothing can connect to it now.

    I've been using the IPC this way for several years and I have never seen this behavior until now....

    Anyone have any ideas???

  12. Jon O

    Aug 9 Pre-Release Testers, Xojo Pro Chicago Area USA

    I believe I have developed a workaround for this. Instead of calling Listen first, I check to see if there's a Mutex that I can enter. If I can, then I know I am the first app running and can call Listen. The second app comes on and checks to see if It can enter the Mutex and can't, so it connects.

    When the socket disconnects, I attempt to leave the Mutex, etc.

    So far it seems to work...

  13. Michael D

    Aug 9 Pre-Release Testers, Xojo Pro

    Another technique that's useful: if app A is launching app B, then app A can pass in the IPCSocket's path to let the other app know what it is (this can be done on the command line, or using environment variables...). This only works if one app is launching the other, though.

  14. Jon O

    Aug 9 Pre-Release Testers, Xojo Pro Chicago Area USA

    @Michael D Another technique that's useful: if app A is launching app B, then app A can pass in the IPCSocket's path to let the other app know what it is (this can be done on the command line, or using environment variables...). This only works if one app is launching the other, though.

    If only it were that easy! In this case they are two independent apps. One is a desktop version and one is a standalone web app. I want to be able to sync data between them when both are running (it's a video control system) so that when a user makes a change on one platform, it's updated on all the others. The problem is I just never know which is running in the first place.

    My long term goal is going to be to completely decouple both the desktop UI and the Web UI from the backend operations of the app. I've started this (and it should have been done this way from the get-go but 9 years ago I was just learning RealBasic) but it will take a while to finish. Once I get that decoupling done, the web app engine will do all the heavy lifting and run as a service in the background. The desktop app will then use IPC exclusively to send commands to the web app and get data back. Then I don't have to worry about this because I'll always set the Web app service to listen on IPC.

  15. Julian S

    Aug 9 Pre-Release Testers, Xojo Pro UK

    Probably a daft question, why don't you call connect first? If that fails, no apps are listening, so switch that app to listen? (remembering to close the failed connect socket before you listen)

  16. Jon O

    Aug 9 Pre-Release Testers, Xojo Pro Chicago Area USA

    @Julian S Probably a daft question, why don't you call connect first? If that fails, no apps are listening, so switch that app to listen? (remembering to close the failed connect socket before you listen)

    That is what I do actually now that you mention it. I don't first call Listen. I call Connect and then if nothing is there I get a 103 error where I then close the socket and set it to listen.

    OK. So maybe I was testing things backwards this morning with the example apps trying to listen first....

  17. Julian S

    Aug 9 Pre-Release Testers, Xojo Pro UK
    Edited 2 months ago

    Ah ok, cool. I just mocked up a little test here and it works, but you have to close the socket after the connect fails or you get the problem you mention when you call the listen, nothing can connect back to it.

  18. Jon O

    Aug 9 Pre-Release Testers, Xojo Pro Chicago Area USA

    @Julian S Ah ok, cool. I just mocked up a little test here and its work, but you have to close the socket after the connect fails or you get the problem you mention when you call the listen, nothing can connect back to it.

    I think what might be happening is that I attempt to connect to the socket. During that time (and before the failure with error code raised) I am attempting to write to the socket. No, just tried that in the example apps. That doesn't cause the issue.

    I must be calling listen improperly at some point. I'll have to see if I can track that down....Seems like once error code 105 gets thrown then the socket is hosed...

  19. Michael D

    Aug 9 Pre-Release Testers, Xojo Pro

    I can't connect to feedback.app right now, but I remember there were some old bugs on Win32 builds where you had to call socket.Poll() a few times before the .connected value was correct. This could lead to it looking like a connection failed when it had actually succeded.

  20. Jon O

    Aug 9 Pre-Release Testers, Xojo Pro Chicago Area USA

    I'm running Win64 though so who knows.

    Well, my customer just got back to me and it looks like the version using the Mutex is working great. I'll have to track this down - why I am calling listen out of order...

  21. brian f

    Aug 9 Pre-Release Testers, Xojo Pro Chilly California

    @Jon O I'm running Win64 though so who knows.

    Win32 is Microsoft's naming convention for the Windows API

    Microsoft X86 and Microsoft x64 (Platforms) and Microsoft Win32 API for x86 and x64 builds

    It's a crazy world!!

or Sign Up to reply!