How does rFactor verify files between a remote DS and a local Installation?

Frank Geyer

Hi there,

you don't have to go into very deep details or present the actual code ;) ...

I only would like to know how rFactor is comparing files (remote DS <<< >>> local Installation) deciding to throw out a mismatch exception, meaning what are the criteria for throwing out an exception like this?

Is it by:

1. comparing a checksum
2. comparing the timestamp of last file change
3. comparing the file size
4. a combination of 1 - 3
5. none of the above

Thank you very much in advance !!!

Cheers
Frank

EDIT: Mainly I would be interested if the MODIFIED DATE of a file ever plays a role !?!?
 
Last edited:
Been meaning to do a quick check on this myself, so based on some tests modifying a HDV file I can rule out No. 2.

Modifying even a commented line in the file, even with just a space at the end of it, produced a mismatch. Editing it back to the way it was, even with the new timestamp, worked fine.

I doubt the entire file gets uploaded, so a checksum seems most likely. (I think your options 1 & 3 will be difficult to separate in practice)
 
Hi Lazza,

first of all thanks for your reply!

If have done the same testing and came up with the same results. But like almost everything else in the world: You don't really know unless you have been told by the one who knows. ;o)

I also can think about a way, when the client loads the vehicle while connecting to the DS, the client computes a checksum locally over the relevant files for its vehicle, sends the checksum to the server via UDP / TCP (!?!?) compares the results and acts accordingly compared to the computed result at the DS ...

What I am trying to accomplish is to eliminate my doubts in a way of keeping rFactor Mods in sync by means of FTP synchronizations.

If the boys from ISI are going to state that the MODIFIED DATE isn't taken into account and the sync process has been run successfully according to its log file and after I have personally verified that the claimed files are identical, then there must be something happened in between with the corresponding files.

A 2nd thought is, when drivers using a patched rFactor executable like a NO-DVD-Patch and the way of validating the local vehicle against the DS vehicle is compromised by an executable like that.

Cheers
Frank
 
So you have had trouble with mismatches using a sync system?

Unless different files are handled differently, a non-mismatch on a different timestamp should rule out the possibility it's being used. I realise straight from the horse's mouth is best, but there aren't many possibilities and tests should prove conclusive.

I'd be surprised if any 'patched' EXEs caused problems, unless the... er... 'patching' was done particularly badly. Having it cause a mismatch would be a bit like Ferraris being rendered green, or wings causing lift, etc.

Still, if you're getting some weird results it's worth investigating.
 
No, not with the actual sync systems. The sync log was fine. The corresponding files claimed by the mismatch were fine when I looked at them.

So when the ISI boys say, no timestamp at all from any file will be taken into account for comparing the local vehicle with the remote DS vehicle, then there is only one possibility left ... if you know what I mean ... sadly !?!?
 
I'd say fair play to the isi chaps actually. buy the game ffs.
 
@Alex: For being polite in the first, hoping that I get u wrong ... what's your point ffs?

FYI! I am not searching for a way to protect cheaters and cheapers ... I am trying to provide an Endurance Racing environment based on rFactor, not excluding any aspect to make such events as stable as they can possibly be ...
 
Sorry, when I asked if you were having problems with the sync, I meant getting mismatches after sync'ing files, so I guess that's a yes. Interesting.

For what it's worth I've known a couple of people who, for whatever reason, had trouble getting the game to activate properly and used a 'patched' exe... and had no mismatches. (before anyone chimes in, yes, they had bought the game, and it was probably something dodgy with their windows or something, at the time for them it was the easiest solution... not something I'd normally condone...) Still, there could be various patched versions so I guess it's feasible.

Is it possible the FTP transfer is altering the end-of-line sequences (CR + LF vs only CR, that sort of thing) and ending up with a different file in that way? Depending how you've compared the resulting files to your originals you might have already ruled that one out, I know.
 
I'm quite sure that rFactor doesn't check any filedates for the mismatch check. I think they will use some kind of checksum like CRC32 or so for the check. But as you said, you can not be 100% sure unless you get some offical answer.

If you are transferring in ASCII mode (or automatic mode and the file is recognized as a ASCII mode file), it's possible that the fileendings get changed according to the target system like Lazza said. In that case the file "looks" correct, but will have a different checksum (and filesize i think).
In binary transfer mode, the file should remain unchanged (except of the file dates which are usually not get transferred with ftp).
 
@Achim: Did a file md5 checksum check on the appropriate file(s) and the results were equal after the sync. only the last modified date were different.

@Lazza: Unfortunately there is no comment from the ISI boys :( on that. So far, because I am a lazy a$$, ;o) I let WinSCP do all the work. Unfortunately in batch mode of WinSCP while using "synchronize local -delete -mirror -criteria=both" there is no "-preservetime" like in the "get implementation" of WinSCP. Furthermore there is no "XCRC, XMD5, XSHA" at all with the FTP-Protocol in WinSCP, so I guess I have to write my own sync to implement these functionalities. The next step would be writing a service which controls the running instance of the rFactor client locally to make sure the drivers using the unchanged rFactor files verified by a checksum while connected to the server. A third step with this local service could be reporting all local processes, so that you are at least aware of these processes which are not running under a self implemented root kit to detect ram-chests in comparison to a black list of such programs ...

So long.
Frank
 
And you have had a mismatch on that file even after verifying that the md5 checksum is equal? Very strange...

Good luck for your other projects. Hopefully you can use your work together with rFactor2. It would be a shame to do all this work only for a game that no one wants to play after rF2 is released.
 
@Achim: Not really. Because there are so many rumors around rFactor that makes me vomit! One is the "-trace=1000". Another one is the "possibility to change the GenString=" in the .veh file, and people think it doesn't interfere game play but all over sudden these clients receive a "Vehicle collision mismatch"! A third one is the implementation of an unsupported Recon Lap by "MULTI Reconnaissance="1"", with the explanation to give the rFactor Dedicated Server time to settle on network while clients are synchronized when switching sessions with a high amount of connected clients on a "Windows XP Server" with an "On-Board Desktop NIC". And we both know where those rumors at least in Germany started to develop ...

Secondly, this hasn't anything to do with luck! If rFactor2 brings all the features with it by itself, I am more than just pleased. And nil is really for nothing. At least it might be an inspiration for others who are really capable of programming like the guys from SimRacingServers24, which by the way really looks pretty promising !!! But I didn't expect anything else such statements like this from you, and this says it pretty much if one doesn't know you better. Just thinking about your failure of trying to implement such functionalities during a recent big event in Germany.
 
You must log in or register to reply here.

Back
Top