A FILE AND RECORD LOCKING UNIT Copyright 1995 By Michael Tischer and Bob Dalton INTRODUCTION: ------------ What makes a door multi-node or on-line multi-user capable? The answer is the use of file, and more importantly, record locking to share data files between multiple copies of the same program running in memeory. This unit adds those functions to the DDPlus package. The NETFILEP.PAS code included in this archive is FREEWARE and can be used in any manner you want and without cost, but remains copyrighted to Michael Tischer. Everything else is copyrighted by Bob Dalton. I have made several changes to that unit to allow them to function better with DDPlus, so blame any errors from changes on Bob Dalton. I do not profess to be an expert on this topic, but not much help seems to be available about this topic so I have decided to take a swing at it. Feel free to send me further information or possible additions and/or corrections to this document. REQUIREMENTS: ------------ At this point in time the only requirements are that you must be using Borland Turbo Pascal version 6.0 or 7.0. I compiled the unit with Borland Pascal 7.0 Professional and know it works. I expect it will with TP 6.0 as well but can't guarantee it. Be sure to have already compiled the DDPLUS.PAS unit BEFORE compiling this one. Also when used in your programs you must warn the sysop that he/she MUST have DOS Share loaded. Files Included -------------- Below is a listing of all files for the LOCKING.ZIP Package: GAME.CTL - Required Configuration file for the LDEMO.EXE Program LOCKING.DOC - The text file you are reading. LDEMO.EXE - Compiled version of the LDEMO.pas program. So you see it in action immediately and see how file and record locking work. Not fancy, but it does the job! LDEMO.PAS - Source code to the Ldemo.exe program. NETFILEP.PAS - The locking routines unit by Michael Tischer. Installation and Preparation for Use ------------------------------------ 1. Move the archive package to a temporary directory and "unzip". 2. Try the LDemo.exe program first to see the end product BEFORE looking at the code in the provided units. It will give you a better feel for what is going on. Note: It's a door program so be sure to use the /L parameter. Example: LDEMO.EXE /L 3. Before compiling the NETFILEP.pas unit be sure that your compiler knows where to find the listed units. 4. Add NETFILEP to the "Uses" portion of your program and call the procedures as needed and shown below. 5. That's it! Enjoy and good luck. ABOUT FILE MODES ---------------- I recommend that you use only two filemodes: 64 (read) or 66 (read write), because I have found them to work the best and are the ones most trouble free. Here's a map of valid values for FileMode: ----- Sharing Method ----- Access Compatibility Deny Deny Deny Deny Method Mode Both Write Read None --------------------------------------------------------- Read Only 0 16 32 48 64 Write Only 1 17 33 49 65 Read/Write 2* 18 34 50 66 * = default FILE LOCKING VS RECORD LOCKING: ------------------------------- File locking may be used for typed and text files. I have found file locking to be most appropriate if there is only ONE record in the file or it is a text file. In the case of non-text typed files I would suggest that you consider file locking be used whenever you are going to overwrite the ENTIRE file and not just a portion of it. Record locking may only be used for typed files and NOT text files. Record locking is most useful when you only need to change 1 or more records in a file that contain many of them. A data base file is a good example of this. Record locking allows others to access non-locked records. File locking does NOT allow this, as it is ALL or nothing. To use record locking you must use the reset command first. Re-write is NOT used with the record locking commands. In multi-node and on-line multi-player games I recommend that you use the locking and unlocking routines in some type of loop to allow for the fact that others might be trying to access that same record. Without a loop it will fail and generate an error otherwise. Another recommendation is to disable I/O checking to prevent unwanted error reporting and system slow downs. One other thing I learned the hard way about record locking. To read or write a record you must know the record number. In your record information assign a variable at the top of the list where you will store a record number. These always begin at 0. See my LDEMO.PAS program for an example of this. You can always search the record based on an of the list variables you have. Good example would be to find a player by the name of "BOB DALTON". Search on that name until you find it and then you automatically know the record number because it will have it's own variable. Again I know this may be confusing and hopefully the example LDEMO.PAS program will make it more clearer. STRATEGIES FOR ON-LINE MULTI-USER DOORS --------------------------------------- The main problems on the best way to update records and keep information current seems to lie primarily with games, but can also apply to any door where several people have access to records at more or less the same time. Game maps are a good example of this. If you are using a map in your game I would suggest you consider each movement space on the map as a separate record in a map database. Doing it this way makes it easy to update and prevent access problems and wrong information. When a player LEAVES his current position on the map a procedure should be called to update that map position record in the map database. Conversly when a player enters a new map position you need to call a procedure to read the map record for that position from the map database file. It may not be the best method, but it works. The downside to this is a lot of disk accessing always going on. Whenever information changes on a door user you should consider re-writing the users database file record. Not doing this means that if another player accesses information on that user, it will be old information and not correct. I know this can be confusing, but writing an on-line multi-player game is NOT easy for the novice as there are many issues to be addressed. In my door games I have set up a looping procedure that constantly writes the players current information to his database record and then immediately reads that same record again to check for changes inflicted on the player by other on-line players. Again maybe not the BEST method, but it works. Just remember that when you write the current users information to his record that it is being OVERWRITTEN completely by the new information. Conversely when you read that record it is completely overwriting that record information in MEMORY for that user. Just food for thought.... THE LDEMO.PAS PROGRAM --------------------- Also included in this package is LDEMO.EXE which is a sample door program that demonstrates file and record locking much easier then I can explain it to you. The LDEMO.PAS file is the commented source code that's shows you how everything was done.