Winsock is hard to code for in my experience - one byte misread and the whole thing can stop and it's often very hard to find that offending byte.

It's always better if possible to use higher level protocols. I'd recommend HTTP if at all possible - there are a number of ways you can get VFP applications to host a Web server, or host IISExpress and channel requests into a FoxPro app from there.

Another alternative - recent HTTP WebSocket protocol libraries - make it possible to use much higher level interfaces to communicate via Web Sockets. This is HTTP like but with the ability to push data just like sockets. Again the advantage is that the protocol isn't at the transport level but rather at the prtocol level where you simply work with endpoint messages which is much easier to work with and therefore more reliable. I haven't tried this from inside of VFP, but it should be possible to reverse engineer a client for somehting like SignalR or socket.io and make it work from VFP, or even integrate it through a Web Browser control and just use JavaScript for the IO code.

+++ Rick ---

>Looking for experienced advice re port listeners.
>
>We have customers whose Cloverleaf system relies on ports to communicate data messages to other systems, including ours.
>
>We have a small VFP app that uses Winsock to listen to the port. We used VFP because this thing may have to run on really old machines and it's great to be able to copy VFP exe and runtimes to a machine where you can be confident it will work immediately.
>
>When the app receives a message via the port, the app saves it into a folder and signals success. That's all it needs to do.
>
>Problem is that this port listener exe freezes. Then messages are dropped and we're in limbo until somebody notices and restarts it, at which point it runs fine until the next freeze.
>
>Does anybody have experience with port listening, e.g. via some other mechanism more reliable than Winsock?
>
>Also, as a related matter- ideally this app would run as a service so that if it fails it can shut down and be restarted automatically by Service Manager. But the developer says this does not happen, apparently because VFP lacks the "hooks" needed by Service Manager to oversee service availability. If the exe crashes or shuts down, apparently Service Manager thinks it's still working fine. I have reviewed Calvin's blogs and other material on this and see no reference to this issue. Is it true- IOW if a VFP service freezes or crashes out, does it really not get restarted by Service Manager? If so, does anybody have a better solution to work with port listening, or even if you confirm that you have VFP services doing other stuff under expected Service Manager control, iow restarting if required, that would be a great help.