I need to interface with a remote HTTP server in both directions. In other words PAC needs to be able to GET/POST to the remote server and the remote machine needs to be able to POST/GET to the PAC. The remote server has a custom API that I need to implement.
Is there a way to extend the PAC REST API to add additional services so that these services can coexist with the existing REST services?
or
Do I need to implement a new interface at the TCP level?
and/or
Can I use the GetHTTP and PutHTTP functions to a unique port so as to not conflict with the builtin REST API using port 80? ie can I specify port 12345?
If you want to leave the PAC RESTful API port on 80, then there is Option 2.
You can specify any port that your remote server is listening on in the PAC Control comm handle configuration.
From the PAC Control command quick reference;
I don’t think this is possible, you can change the port the API uses, or you can use a different port for your custom server. (Beno’s got you covered here)
Probably. See PAC Web server for a web server written by nick_stephens - may have a lot of the work done that you are looking for.
If these are shorthand for Opto functions - there is no HTTP Put - just get and post.
I’m not sure, I suspect you could loop on the Get Characters function as long as the TCP socket is still open with a client, but when a new client connects, then you may need another Accept Incoming Communication. And how would you handle simultaneous clients, I have no idea - can’t exactly start another thread… I would have to test this, the documentation isn’t real clear in this area.
Yeah, you don’t want to do that. - I notice that the web server sample I linked you to does this, that isn’t right, as you want to leave the comm open if you expect more communications.
From the docs: “When using TCP communication handles, keep in mind that the controller has a limited amount of TCP/IP resources, so you need to be careful about how frequently these communication handles are opened and closed. TCP communication handles are meant to be left open as long as possible.”
I will only have one persistent client forever unless it fails or drops, so I can test for comm open also. My initial attempt was looping on characters available, then if so read them in otherwise delay a bit and check available again. I think I am getting closer on this though.
I did some testing on listening for TCP connections and here is what I found works:
Start by calling Listen for Incoming Communication. This opens up the port and can be a different comm handle than the one you use for Accept Incoming Communication - which is useful if you want to handle more than one client (one comm handle per client).
If the port opens okay then loop on Accept Incoming Communication. The command will time out every ~10 seconds with -442 if a client doesn’t connect and you have to call it again. If it has an error other than -442, you will most likely need to go back to Listen for Incoming Communication to reopen the port. As mentioned above, you can use a different comm handle if you want to communicate with multiple clients simultaneously. I have more information on that if you need it.
Now that you have a client connected, you can loop on Get Number of Characters Waiting until you see some data. If the socket goes down (negative result from the call), then you want to go back to calling Accept Incoming Communication until the client connects again.
