Scott Some comments on your code logic please (all meant in the spirit of co-operation, NOT criticism):
1) dstar_register_rptr. You use the call strcpy(ip, inet_ntoa(ia)); However ia has already been set to the IP Address of the Trust Server. If this is a registration, the IP address sent in the initial sequence should be a subnet-zero unique 10.X.X.X address with a /28 mask. Once the Trust Server has authorized the connection, then the dstar_ip_check should use the IP address from which it reported - the Trust Server will use the source IP of the incoming check and place that against the Zone RP details in the GIP database. dstar_ip_check therefore needs to obtain that IP address from the GIP table and use that once registered. This is important as the real source IP could be dynamic or NAT-ted. So, my understanding of the registration sequence is: - set date to 01-01-1970 00:00:00. - set IP address to unique 10.X.X.X/28 - send to Trust server Polling then continues according to what is received in the database sync. 2) dstar_ip_check. This should really just be a continuation of the above code - startup and polling are really the same thing. Again, there are a couple of issues that I have. - The IP address should be whatever the G2 sync is telling you in the update from the Trust Server. - The date sent should be the last SYNC date from the G2 update. This is VERY important. I'll explain why the last statement. In the correct mode of operation, the G2 system only ever sends a full update ONCE, and that is in response to the date being set to 01-01-1970 00:00:00 as per your registration script. Your poll to the G2 Trust system will thereafter include the DATE of the LAST received update. By that means, the Trust server works out what you have missing, and only sends snapshot updates. As long as you always set the polling date to be that of the last received incoming update, you will never get a FULL update. Now, there is one huge caveat to that last paragraph - that is not how the Live G2 system is behaving currently. However, that is how the Test system beahves. 3) dstar_accept_ip_updates. Your approach here is very similar to mine, except I'm using SQLite to keep the installed code-base size down. Two main comments: - There is a length field in the incoming update which indicates the total size of the data. This is made up of the first four bytes of the update frame. Multiply the first by 0x1000000, the next by 0x10000, the next by 0x100 and then add together, add 0x52 to account for the 44-byte header and the 4-byte size, and you'll get the total expected string length. About 3Mbytes on the live G2 system. - I'm having a real issue processing the SQL anything like fast enough. I'm moving to a batched system in SQLite to try to speed things up, but I notice that you do the same as me which is to effectively stop accepting incoming calls whils the Postgres database updates. This may cause issues on the live network that you don't see on the test due to the size and frequency of the incoming updates. Rather than three separate programs, I've created a single g2_sync process as information from one part is used in the other, but I understand your logic. 73 David- G4ULF
