HTTP Interfacing and ports


#1

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?


#2

Im a bit lost on the first part of your post, but the last bit I get.
Yes, Option 1. You can go into PAC Manager and change the API port to anything.

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;

Once you set the comm handle value, the GET and PUT will use that IP:port.

In other words, you can listen on that new port number, and transmit out of it with the one comm handle.


#3

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.


#4

Im a bit lost on the first part of your post, but the last bit I get.

The Opto22 REST API specifies predefined URI for specific things:

http://hostaddress/api/v1/device/strategy/int32s/somevarname

What if I want to define a custom URI like this:

http://hostaddress/api/v1/myservice/place1

In other words, extend what the built-in API provides.


#5

Ahhhh, Ok, gotchya now.

No. You cant.

(Interesting idea however).


#6

I have a chart implementing a listener and responding to a POST message.

I believe connections are to be persistent and in fact I expect a “heartbeat” GET request to be coming in regularly.

Is it the Opto22 design intent to loop back to Accept Incoming Communication to wait for the next request after I send the 200 OK?

or should I loop back to the Get Number of Characters Waiting function?

In my attempts to get this working right now I am looping, closing the connection and reopening and this makes no sense to me.


#7

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.”


#8

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.


#9

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.