Re: auth handshake and rendevouz objects

[Michal 'hramrach' Suchanek]

An interesting issue overall, hmm.

On Wed, Nov 06, 2002 at 09:42:00AM +0100, Niels M?ller wrote:
> address@hidden (Neal H. Walfield) writes:
> 
> Hmm, all this is about a zero timeout for the send phase of the rpc,
> then we have a separate timeout for the receive phase, which I'm
> afraid can't be zero in our case.
The timeout can be either zero or infinite (until the sending thread is 
killed from outside) or you cannot guarantee anything.
> 
> > >
> > The point is that the server is not suppose to block.  Doesn't this
> > algorithm defeat that?
> 
> The server thread that is responsible for handle transfers from a
> particular client, A, will block if A blocks. The rest of the server
> process will run as normal. That means that the process B that tries
> to get a handle from A will block or timeout when it talks to S. But
> that's no problem, I think, because B would block or timeout in the
> same way if it talked to A directly, so S isn't degrading service in
> any way.

Yes, it's A's thread in the server and it can block it for a priod of time
as long as it wishes. As somebody suggested already that resources for
processing server request (ie memory) should be supplied by the client,
B could even provide the resources to construct it's own server thread 
for any future communication.

But a simpler thing would be to limit the receive in the client to the 
target server thread (if possible) That way there can be a thread pair:
a worker thread and a receive thread. Each time a RPC in the work thread
is attempted receive thread is limited to messages form target server thread 
before the request is sent. The message from server is sent immediately.
The problem is any requests that take too long have to be cancelled to 
implement a timeout or a new receiver has to be created when a timeout occurs.

> > handle thread must do an open wait and as such the possibility exists
> > that its thread id will be guessed by a rogue process.
> 
> All threads *must* be able to copy with occational invalid messages.
> The problem is how to prevent it from being flooded with invalid
> messages, like a denial of service attack. I think it should be
> possible to limit the damage, by counting the cpu resources used by a
> task as the actual cpu usage + a constant times the number of rpc:s

What about passing the CPU along with the message. A recieving thread cannot
have a cpu when it waits and the sending thread should be scheduled to
be able to execute the send. The rest of it's time quantum or whatever
can be spent by the other thread.
At least one thread should be waiting (either sender or receiver) or
the message cannot be passed as it is synchronous.
The attacker would give it's cpu time to random threads ;)

-- 
Michal Suchanek
address@hidden