WC and server time/date sync
- Thread starter Efried
- Start date
Efried said:
Your server should be running ntp and should never be more than a few tens of milliseconds in error.
The webcontrol will be some time "roughly close"
Always timestamp using the servers (accurate) time and discard the wc time.
What I do (when passing events that could have been some time in the past) is to send "how many seconds ago" it was and do the math on the server, thus eliminating the need for *accurate* time on the WC boards.
Efried
Active Member
I do have two times on the server because the folks from the provider (or GCHQ ;-) ) have set the wrong timezone, and no way to alter that...rossw said:
There is a few times a difference of one second.
What I did not get working is transmitting a feedback from the server returning a value into WSREPLY...
SET WSRPLY 0
WEBSET URL8 CTS
SET RAM8 WSRPLY
via this line in the php script called by the WEBSET:
echo "SET_WC=".$status."\n";
Here's a couple of snippets from some of my code thats been running for over a year now with no problems, no rebooting etc:
MAIN:
TSTNE VAR1 0
GOTO MANUAL
SET WSRPLY 0
WEBSET URL1 12
SET RAM2 0
LP:
SET VAR4 WSRPLY
TSTNE VAR4 0
GOTO SETPOS
INC RAM2
TSTLT RAM2 2000
GOTO LP
And server-side:
#! /bin/sh
echo "content-type: text/plain"
echo ""
d=`date +"%d-%b-%y %H:%M:%S"`
{proprietry code snipped}
if [ -n "$update" ]; then
echo "SET_WC=1xxxxxxxxxxxxxxx"
exit
fi
{lots of other code for different conditions}
I recall finding that it was CRITICAL to add the extra padding digits after the SET_WC= or return values were simply not being parsed. It may have been fixed since, but I think it had something to do with the processing time of the command, and the memory scavanging in the WC.
MAIN:
TSTNE VAR1 0
GOTO MANUAL
SET WSRPLY 0
WEBSET URL1 12
SET RAM2 0
LP:
SET VAR4 WSRPLY
TSTNE VAR4 0
GOTO SETPOS
INC RAM2
TSTLT RAM2 2000
GOTO LP
And server-side:
#! /bin/sh
echo "content-type: text/plain"
echo ""
d=`date +"%d-%b-%y %H:%M:%S"`
{proprietry code snipped}
if [ -n "$update" ]; then
echo "SET_WC=1xxxxxxxxxxxxxxx"
exit
fi
{lots of other code for different conditions}
I recall finding that it was CRITICAL to add the extra padding digits after the SET_WC= or return values were simply not being parsed. It may have been fixed since, but I think it had something to do with the processing time of the command, and the memory scavanging in the WC.
I understand that the webcontrol parses to the first non-numeric character.Efried said:
My testing at the time indicates it stops at the first non-number character *PROVIDED* there are enough characters in the buffer for it to have enough time to decode them all before the buffer itself is released. If you like, I'll try to find my notes at the time that indicated just how many were required.
Efried said:
OK, Couldn't find anything in my email, but did find it in an IRC log. Small excerpt quoted here:
08:58:00-28/03/13| <CAI_Support> Basically to make WEBSET read back reliably, it is better to have some data bytes after valid data, so that server will send FIN later.
08:58:06-28/03/13| <RossW> I can change it to always return you something constant if you wish, but the problem is that the WC seems to be truncating the answer.
08:58:27-28/03/13| <RossW> yes, I have had to add about 12 bytes after the reply....
08:59:04-28/03/13| <CAI_Support> That is fine, you need to test out a reliable range for server CGI to send, and WEBSET to receive.
09:00:04-28/03/13| <RossW> Wayne: can I suggest that that be made clear in the documentation for the CGI? It seems really odd that we have to put
"junk" after the reply just to get it to process
09:00:49-28/03/13| <RossW> When I initially wrote my CGI, the webset command was getting NOTHING back at all... and it took a lot of digging to figure out what was going on.
Efried
Active Member
In addition, and after a hard night having now very slow server response, I have added some waiting routines, until WSRPLY is here with a non-zero value:
TSTEQ WSRPLY 0
WAIT 500
but this is not very elegant, and does not work if the server is disturbed....
Why it is disturbed? I don't know the slow response might have something to do with the fact that I'm dencrypting data stored on the server using PHP, which will be then returned to the WC (also modified using a rolling key). All in all the securer the system the more fragile with regards to timing...
I also fear to have been run into another problem:
daylight saving might not by switched on autmatically in the WC?
thanks
TSTEQ WSRPLY 0
WAIT 500
but this is not very elegant, and does not work if the server is disturbed....
Why it is disturbed? I don't know the slow response might have something to do with the fact that I'm dencrypting data stored on the server using PHP, which will be then returned to the WC (also modified using a rolling key). All in all the securer the system the more fragile with regards to timing...
I also fear to have been run into another problem:
daylight saving might not by switched on autmatically in the WC?
thanks
CAI_Support
Senior Member
Ross is correct, if you want to enable day light saving, you will have to do it in PLC code, we have examples posted in this forum before. The reason is that there are just so many different timezones and different dates for day light saving to start and to end.
Efried said:
1. The WC uses ntp
2. You will never get *EXACTLY* the same time. (I have a heap of devices and even using precision GPS time references, it's hard to get better than within a few tens of nanoseconds)
3. How close to the same time do you really need?
4. Why do you (think you) need such precision of time?
5. It is easy enough to set a webset to query your server for local offset (eg, start of end of daylight savings), and add an offset (which may be 0 or may be an hour), as and when your server determines daylight savings starts or ends.
6. Skipping DST is the smartest thing anyway. When you have stuff in countries all over the world in a plethora of timezones, the only thing that makes sense is UTC.
Efried
Active Member
rossw said:
Many thanks for explaining. The accuracy is not the problem right now, just the DST changing one hour and breaking the encryption/decryption in the WC to Server communication.
If I may alter the WC time through the WC code (PLC) myself, then I could sync the DST between WC and server, if any. Unfortunately this would eat up another notification variable for WEBSET.
