[lug] socket programming/kernel question

[Zan Lynx]

On Wed, 2003-03-05 at 11:17, Bear Giles wrote:
> Michael J. Hammel wrote:
> > You have two processes that know about each other, correct?  Or does
> > your process know about the others, but the others don't know about
> > you?  I'm guessing the former, based on your description.
> 
> There's a key server daemon, which knows the pid of callers from 
> the SCM_CREDENTIALS information attached to the Unix socket 
> message.  The clients who know nothing about the daemon - they 
> just open the socket connection and send stuff through it.
> 
> There's no logical connection between the processes, so having the 
> server act as a factory isn't a practical solution.  (The server 
> will probably be in C, the clients java applets triggered by 
> asynchronous messages.  That also makes it difficult for the 
> client to use a gatekeeper.)
> 
> > If both know about each other but you want asyncronous message handling,
> > then TCP is the best way to go about it.  EPIPE can be used to know when
> > the opposite end goes away.  Trying to do it by process id is far more
> > difficult.
> 
> The more I think about it, the problem isn't detecting when the 
> connection drops, it's detecting that the other process has died. 
>   Information needs to go down the rabbit hole.  Stream protocols 
> would tell me this, but require me to keep the stream open for the 
> lifetime of the process even if days pass without use.
> 
> > I find that UDP is better for situations where the sender doesn't care
> > about the receivers status.  This doesn't sound like the case here.
> 
> It's also useful for cases where the requests are idempotent and 
> have no logical connection to other requests, and that's the case 
> here.
> 
> I haven't worked through all of the details (since I'm also 
> considering other approaches), but the idea is that you hit the 
> server with a one object and it echos a modified object, or it 
> remains silent and the client times out.  If the client misses the 
> response (unlikely on Unix sockets :-), they can resubmit the 
> request without causing any problems to the server.
> 
> The twist is that authentication is necessary, but nothing the 
> client provides can be trusted.  Hence Unix sockets and the 
> SCM_CREDENTIALS - it's not much, but it's a start.

How about a cryptographic cookie in each request?  Doesn't secure NFS do
something like that?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20030305/547162c8/attachment.pgp>