You are looking at an old piece of source code. The new one access the gip.
And 2 Linux servcices,not 3. I prefer the "RECEIVING IP updates" to be in a different logic from the "SENDING IP updates". Glad you are looking at my source code, bu that is a very old program. Scott. --- In [email protected], "dlake02" <dl...@...> wrote: > > 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 >
