A few reloads shouldn't cause much of a problem (if any). Reloading the
filters is a pretty straightforward and fast operation from MultiNet's
standpoint, and doesn't require a system reboot. The basic algorithm is
"if filters are loaded, release the chunk of memory that holds them back to
pool; allocate a new chunk of pool; load the filters into it; start
running". Fragmentation shouldn't be an issue.

I suggest you might want to submit an enhancement request for SSH to have
it look at the DENY lists a bit earlier in the game than it does now. I
would have to think about the ramifications of doing so before being able
to commit one way or another to doing something about it.

At 11:28 PM 6/30/2006, Jeremy Begg wrote:
>Hi Hunter,
> >I think the only way to do that would be to set up packet filtering to
> >block those. Rules like the following would allow only the specified
> >hosts (or subnets) to connect:

> >!
> >! Allow certain address to connect via SSH
> >!
> >permit tcp 0 0 eq 22
> >permit tcp 0 0 eq 22
> >!
> >! Deny all others
> >!
> >deny tcp 0 0 0 0 eq 22

>I was thinking that packet filters might be the (only) way to do it.
>However I was also under the impression that changing them required a system
>reboot. If this isn't the case then I think I'll give them a go!
>How efficient is MultiNet when it comes to reloading the packet filter file?
>I'm thinking that if the server is up for a few hundred days -- as is often
>the case with VMS -- and I reload the packet filters a few times a day, will
>performance be adversely affected? (E.g. memory pool fragmentation?)
> Jeremy Begg

| Dan O'Reilly | "There are 10 types of people in this |
| Principal Engineer | world: those who understand binary |
| Process Software | and those who don't." |
| http://www.process.com | |