[erlang-questions] A sender() BIF?

[Keis, Andrei]

I think the focus here should be on remote node authentication (and network identity of the sender process) rather than reply pid, which is part of the message data. 

If we focus on remote node authentication vm help is needed. There are two ways to implement authentication - message level, and I can add security context as a field in the message similar to 'reply-to', or when establishing link. 

Having security context per message requires implementing custom protocols and will not cover built-ins. 

On the other hand, for transport level security it is possible to implement some sort of pluggable security exit when link is established (replace cookie system with Kerberos for example), so vm will know network identity of the remote side. It is easy to do, but this info is lost in the receive loop.

For example, if it is possible to extend the syntax of receive:

  receive { ... } from { Princ } -> ...

vm should know where this message is coming from, and Princ can unify with anonymous, local, or { krb, ... } and so on. If I care, I will include this in the loop, if not, just omit the 'from' from the loop and it is backward compatible. 

 

> -----Original Message-----
> From: erlang-questions@REDACTED [mailto:erlang-questions@REDACTED]
> On Behalf Of Richard O'Keefe
> Sent: Sunday, February 21, 2010 7:52 PM
> To: Michael Turner
> Cc: erlang-questions@REDACTED
> Subject: Re: [erlang-questions] A sender() BIF?
> 
> 
> On Feb 22, 2010, at 2:20 AM, Michael Turner wrote:
> 
> >
> > It's conventional for certain purposes to make the first term of a
> > message tuple be the sender, where the receiver needs to know.\
> 
> Hmm.  I've always put the 'tag' first, for readability.
> I find
> 	receive {ok,Pid,Data} -> ...
> much more readable than
> 	receive {Pid,ok,Data} ->
> 
> >
> > Recently, I started wondering: why isn't the appropriate sender
> > already
> > available within each receive scope, via a BIF (or even via some
> > special
> > variable)?
> 
> One reason is "because it's not needed", and another has to be
> "because the reply address isn't always the sender address".
> 
> Imagine some sort of load balancing scheme
> 
> 	Client 1			Server 1
> 	...		Router		...
> 	Client m			Server n
> 
> where the router receives messages from clients and redirects them
> to servers, and the servers send their replies straight back to
> the clients.
> 
> Also, consider that sending a message to a process on another node
> doesn't _always_ result in a proxy stub for the sending process
> materialising on the other node.
> 
> > Does the idea of sender() violate encapsulation in some meaningful
> > way?
> > As matters stand, a module just has to take it on faith that a Pid
> > identified as sender in a message actually *is* the sender.
> 
> What it has to take on faith is that the Pid in a message
> identifies the right process to *reply* to, which is different.
> 
> Consider the following scenario:
> 
> 	Self = self(),
> 	My_Helper_Pid = spawn(fun () ->
> 	   do some long computation,
> 	   Other_Process ! {proceed_with,Self,Data}
> 	end),
> 	...
> 	receive {response,Other_Process,Result} -> ...
> 
> If Other_Process relied on sender(), it would send the message
> to the wrong process.
> 
> Having learned about Unix IPC and sockets before Erlang, it took
> me a while to appreciate the fact that the ONLY information a
> process has about a message is the information right there in the
> message, which is precisely the information the sender chose to
> divulge.
> 
> 
> 
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED


--------------------------------------------------------------------------
NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law.