Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Bolt on August 30, 2019, 11:14:18 AM
-
I'm trying to implement the new HTTPCMD into my code. I'm not having much luck. My setup currently works with PING, OPENTCP, STREAMOUT, STREAMIN, STR2INT, etc in multiple stages.
I'm trying to replace the logic with the new HTTPCMD. I'm starting small, just trying to replace the initial STREAMOUT with HTTTPCMD. I've also tried keeping the existing OPENTCP for now.
My current request to server via STREAMOUT is along the lines of "GET http://" FmtInt(D300,ipaddr) "/post/lookup.php?c=" SL[V310] "$0D$0A". This simply translates to "GET http://192.168.0.10/post/lookup.php?c=P-20..", which has worked for along time the old way.
I've tried many versions in the Request box, with and without GET and <CR><LF>, adding the <CR><LF> as Additional Request (help file says with single request Do-more adds it automatically) without all the pointers, without the FmtInt, just as text, etc. No luck. Some versions I get a 200 Response Code, others a 400.
How can I troubleshoot further? Is there a way to get the HTTPCMD activities to log to Do-more Logger? How do I proceed here?
-
HTTPCMD is a standalone function - don't use OPENTCP with it. The URL is built by the command too - input the hostname (192.168.0.10) and the path (post/lookup.php?c=P-20) into the relevant fields. Select the command type (GET) from the dropdown - don't include it in the request.
Think of HTTPCMD as a wrapper for OPENTCP/STREAMOUT/CLOSE.
-
I'm trying to implement the new HTTPCMD into my code. I'm not having much luck. My setup currently works with PING, OPENTCP, STREAMOUT, STREAMIN, STR2INT, etc in multiple stages.
I'm trying to replace the logic with the new HTTPCMD. I'm starting small, just trying to replace the initial STREAMOUT with HTTTPCMD. I've also tried keeping the existing OPENTCP for now.
My current request to server via STREAMOUT is along the lines of "GET http://" FmtInt(D300,ipaddr) "/post/lookup.php?c=" SL[V310] "$0D$0A". This simply translates to "GET http://192.168.0.10/post/lookup.php?c=P-20..", which has worked for along time the old way.
I've tried many versions in the Request box, with and without GET and <CR><LF>, adding the <CR><LF> as Additional Request (help file says with single request Do-more adds it automatically) without all the pointers, without the FmtInt, just as text, etc. No luck. Some versions I get a 200 Response Code, others a 400.
How can I troubleshoot further? Is there a way to get the HTTPCMD activities to log to Do-more Logger? How do I proceed here?
As was mentioned, HTTPCMD is standalone and doesn't require anything else.
HTTPCMD does output status messages to DMLogger when you set $EnableMsgDump(ST36).
-
It gives the option to use existing connection, so that's how I plugged it into my existing logic at first. I removed it entirely, and I have it working now. Only issue is, using HTTCMD the Server.Connected bit is active for ~15 seconds, using the old stages with OPENTCP, STREAMOUT, STREAMIN, CLOSE instructions, it was ~0.5 seconds. What am I missing here, why is the new instruction so much slower than the old method?
Also, my return string seems to have <CR><LF>0<CR><LF> added to the end. Is there a way I can prevent that, or do I manually have to parse it? I was not looking for it before in my STREAMIN, I took the whole queue's contents. What causes that to be added?
Thanks for the pointers!
-
It gives the option to use existing connection, so that's how I plugged it into my existing logic at first. I removed it entirely, and I have it working now. Only issue is, using HTTCMD the Server.Connected bit is active for ~15 seconds, using the old stages with OPENTCP, STREAMOUT, STREAMIN, CLOSE instructions, it was ~0.5 seconds. What am I missing here, why is the new instruction so much slower than the old method?
Also, my return string seems to have <CR><LF>0<CR><LF> added to the end. Is there a way I can prevent that, or do I manually have to parse it? I was not looking for it before in my STREAMIN, I took the whole queue's contents. What causes that to be added?
Thanks for the pointers!
Are you using HTTPS? Secure is much slower.
-
No, just a local HTTP port 80 on an Apache Server. Much to Google Chrome's disappointment, it's not HTTPS :P
-
As was mentioned, HTTPCMD is standalone and doesn't require anything else.
HTTPCMD does output status messages to DMLogger when you set $EnableMsgDump(ST36).
Ah, too many choices in the HTTPCMD box. It gave me the option to use existing OPENTCP...
That's what I was forgetting, ST36. Thanks. Here's a DMLog:
192.168.0.91 Port 29298(0x7272),08/30/19 11:56:37.476 ,"HTTP disconnected!"
192.168.0.91 Port 29298(0x7272),08/30/19 11:56:37.475 ,"Disconnecting HTTP..."
192.168.0.91 Port 29298(0x7272),08/30/19 11:56:37.474 ,"Server connection closed."
192.168.0.91 Port 29298(0x7272),08/30/19 11:56:22.423 ,"Accept-Encoding: identity.."
192.168.0.91 Port 29298(0x7272),08/30/19 11:56:22.423 ,"Host: 192.168.0.10.."
192.168.0.91 Port 29298(0x7272),08/30/19 11:56:22.420 ,"GET /post/lookup.php?c=P-10 HTTP/1.1.."
192.168.0.91 Port 29298(0x7272),08/30/19 11:56:22.420 ,"HTTP connected!"
192.168.0.91 Port 29298(0x7272),08/30/19 11:56:22.419 ,"Connecting to HTTP server..."
-
Looks like one side or the other is waiting for something. After 15 seconds, the server gives up and closes the connection.
-
Any ideas on what to look for? As soon as the disconnect happens, the output string is populated with the same contents as before, with an extra <CR><LF>0<CR><LF> added to it. So it's getting everything it needs, just not acknowledging it or something, and waiting for the 15 second timeout. In that 15 seconds, I can't even force it to stop with a DEVCLEAR or CLOSE instruction. I've cleaned up my code allot, but still it goes 15 seconds every time. I've had to revert back to the old code to keep the speed up, 4 per minute is not adequate.
-
You might try installing Wireshark to see what's actually coming in over the wire. Is it a new server application? - perhaps the issue is at the server?
-
I have not put wireshark on this network.
I doubt it's a server problem, it's an existing server, that's communicating well with the PLC via existing PING, OPENTCP, STREAMOUT, STREAMIN, CLOSE instructions. <1/2 second connect, response, close.
Replace it all with HTTPCMD, connection dropped after 15 seconds, but still receives the expected response in that time.
While the connection is open for 15 seconds, I can send another OPENTCP, STREAMOUT, STREAMIN, CLOSE to the same server via another TCP Device on the BRX, and again, get a <1/2 second connect, response, close.
-
Do you still have the trailing CRLF on your request? You'll want to get rid of that. Could you post the contents of SL3?
-
/post/lookup.php?c=P-10
-
Do you have anything returned in D320?
-
I have 200 as a Response Status Code
-
Here's a screenshot of wireshark, I'm not really sure what I'm looking for. It is worth noting that the /post/xxx.php request doesn't show up on the wire until after the 15 second disconnect. And it's all addressed to UDP to 255.255.255.255? I can't find any source or destination containing the server's IP in the time period involved here.
-
The difference is really this pronounced. Check out the Trend View attached. Same request to the same server, same response, one via HTTPCMD, the other via OPENTCP, STREAMOUT, STREAMIN, CLOSE.
-
Make sure you have the IP address formatted correctly in D300. Each octet is a byte so for instance if your server IP address is 192.168.12.34 the memory locations would contain:
D300:UB3 - 192
D300:UB2 - 168
D300:UB1 - 12
D300:UB0 - 34
The native equivalent value of this IP address would be -1062728670
-
IP address is correct.
My SL3 via STREAMOUT is "GET http://" FmtInt(D300,ipaddr) "/post/weather.php" "$0D$0A" response into PLC within 1/2 second
My SL3 via HTTPCMD is /post/weather.php response into PLC over 15 seconds
-
Do you have any filtering switched on for the Wireshark capture or display? There are two - one you set when you set the interface you want to monitor, and the other's to filter the captured data once you start capturing.
The best way to set up Wireshark is to use "host 192.168.0.10" in the capture filter and then don't filter the display (at least initially). If you want to run a capture and then send it over I'll be happy to look at it for you. PM me if you're interested.
-
Looking again at the trace screenshot, that's probably a logger message. It's not the GET - that's a TCP message (the one you mentioned is UDP). Take a look at the TCP message at the top of the screen - is that relevant?
-
Starting to think there is a bug. We've had another report that sounds curiously similar. Looking at it now.
-
This might (or might not) be relevant but when I initially started using HTTPCMD I was having trouble connecting to the server. It turned out that if I added a PING first it worked just fine. Here's the thread I started about it: https://forum.hosteng.com/index.php/topic,2649.0.html
-
The issue was in the chunk handling. Not sure how this escaped, because it appears that chunking was always going to be a problem. I know we tested with some chunked sites, but apparently need to add some more.
The difficulty is that there are at least 3 different ways the response payload can be terminated. Trying to handle them all in a single asynchronous state handler is surprisingly awkward.
-
This might (or might not) be relevant but when I initially started using HTTPCMD I was having trouble connecting to the server. It turned out that if I added a PING first it worked just fine. Here's the thread I started about it: https://forum.hosteng.com/index.php/topic,2649.0.html
I was always PINGing before the HTTPCMD, or OPENTCP, either way. Thanks for the re-read, I vaguely remembered that post.
The issue was in the chunk handling. Not sure how this escaped, because it appears that chunking was always going to be a problem. I know we tested with some chunked sites, but apparently need to add some more.
The difficulty is that there are at least 3 different ways the response payload can be terminated. Trying to handle them all in a single asynchronous state handler is surprisingly awkward.
Cool, good to know I wasn't crazy afterall.
Don't forget to remove the existing TCP connection option, https://forum.hosteng.com/index.php/topic,2649.msg21567.html#msg21567 (https://forum.hosteng.com/index.php/topic,2649.msg21567.html#msg21567)
But, I don't think the chunk issue applies to me? I'm just trying to read a <300 character string back into the BRX.
-
But, I don't think the chunk issue applies to me? I'm just trying to read a <300 character string back into the BRX.
It's a payload encoding format that some servers use. Has nothing to do with the length of the payload.