Re: NO multiple logins !! Livingston won't listen
Owen DeLong (owen@delong.sj.ca.us)
Tue, 25 Jun 1996 08:16:24 -0700 (PDT)
> >
> > Limiting multiple logins is a feature of interest only, or at least
> > primarily, to ISP's which offer unlimited access accounts (which is the
> > topic for a whole other argument I DO NOT want to get involved in again!)
> > ISP's who have connect time limits or who otherwise bill for excessive
> > usage generally have no need for this feature. Generally speaking, that
> > is the distinction between people who feel that it is important and people
> > who don't care.
>
> 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.
>
Hmmm....
1. UNIX does support shared memory segments. No agent needed,
a much simpler semaphore system exists.
2. mmap(2) is (for the most part) portable, so you could
mmap your file and have the effect of shared memory.
> 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
>