Gies,Brad wrote: > I'm in the process of spec'ing a .dll that will interface with a ServU > FTP server for the purposes of authenticating users, and I need it to be > very fast, absolutely robust (24/7/365).
Note that your system will only be as robust as the FTP server, database server, operating system, and hardware that you use. > What I've decided to do is that when the .dll is loaded by ServU, it > will go to the database and get a list of all currently enabled users, > and their FTP permissions. Then I want to store that in memory, and when > a new user connects, find the user in memory, and accept or reject them. > If the user is not found in memory, then the .dll would go to the > database to see if that user was added after the .dll was loaded, and if > found add the user to the memory and accept them. What if the user's FTP permissions are changed? If the user exists, then you will have already loaded his or her permissions and would have no reason to go back to the database. A user whose permissions have been disabled would still have access because your DLL is using the permissions that were there when the server was first turned on (which may be many years ago because your DLL is loaded all day every day). > I'm mulling over several possibilities for the in memory solution, A > TList with pointers to the user records, maybe a daisy chain, etc. The > TList solution works if I use a TMultiReadExclusiveWriteSynchronizer and > wrap all read and write calls with that. But I'm wondering if I would > need to do that if I used a daisy chain, because I could allocate memory > for the new record, find where it fits in the daisy chain, make the > entries in the new record, and then change the previous/next record in > the daisy chain. No matter what I wouldn't delete records from memory. The usual term for that is a linked list. If you're asking whether you can avoid multi-thread protection of a list by making it a linked list, then the answer is no. Imagine what would happen if two threads wanted to insert something at the same time, and at places adjacent to each other in the list. Each one would update the "next" reference of the previous item to point to one of the new items, so now at least one of the items is lost, and possibly _all_ the items that would have appeared after it. > There would be a flag in the record as to whether the user was enabled > or not. > > Does anyone have any suggestions before I commit to something? Write it the naive way first. If you later find that it doesn't run fast enough, _then_ spend time and effort finding a faster way. I wouldn't bother keeping a cache at all. Let the database do that for you. The database will already have an index on user IDs, so the lookup should be fast. The human being at the other end of the connection certainly won't notice whatever delay occurs. -- Rob __________________________________________________ Delphi-Talk mailing list -> Delphi-Talk@elists.org http://www.elists.org/mailman/listinfo/delphi-talk
