In MichNet we limit logins to (normally) one session at a time, plus we
have connect time limits for these sessions and we have for fee (billable)
services as well. I guess that means "we care"... :-)
> There are other minor shortcomings that I'll get to in a minute, but these
> are the main problems as I see it.
I believe your logic is faulty in some of your assumptions about "the
main problems". Forking is okay if you maintain session state in file(s).
> Now for my problems: If I were writing this for OS/2, I would have used a
> shared memory segment to hold the table right from the beginning as a
> matter of course, but I don't know how to do shared memory segments in
> UNIX. If I had to do it over (and it looks kinda like I do) I would use a
> file, with appropriate locking to control access to the file, but I don't
> know enough about the various flavors of UNIX to know if the result would
> be portable. At this point I'm hoping that I can use dbopen() and flock()
> and have it work most places.
The flock(2) call is not portable (as I found out recently...)
I'd recommend reading Stevens book on Unix Network Programming.
Regards,
web...
-- William Bulley, N8NXN Senior Systems Research Programmer Merit Network Inc. Domain: web@merit.edu 4251 Plymouth Road MaBell: (313) 764-9993 Ann Arbor, Michigan 48105-2785 Fax: (313) 747-3185