ietf-openproxy
[Top] [All Lists]

Re: P: single assignment semantics

2003-10-30 17:03:39

On Thu, 30 Oct 2003, Andre Beck wrote:

For example, should P be able to block viruses that spread via
simple 10KB HTTP POST requests? If yes, we give network operators
a powerful tool. If not, we tell network operators to rely on 3rd
party modules being available "soon enough" for each new virus.

I am not sure I understand this scenario. Are you suggesting that
there should be P module that provides a function to do the virus
scanning?

Not exactly, sorry for being so cryptic.

I try to think in more general terms while having specific
applications in mind. In this particular case, the application is,
essentially, a virus scanner that supports a single virus that spreads
via POST requests. The general mechanism in P would be something like
a string search within a message body and response generation
(something many proxies already support in one way or another):

        if (request.body contains "virus_signature") {
                generateResponse("request_blocked.html");
                Core.interpreter.stop();
        }

We already know about killer viruses that spread via GET requests. Our
web server logs still get a lot of those requests, years after the
viruses were released. The above interface can filter out GET-based
viruses too, of course. I am sure POST-based viruses either already
exist or will exist. They are more difficult to deal with because
routers and even L7 switches have trouble looking at POST bodies.

Here we concentrate on the ability of a network administrator to block
something like that immediately after reading about it on slashdot,
not via virus scanner upgrades (which is the correct long-term way of
doing it).

One answer could be that something like findVirus(message.body) or
isGif(message.body) MUST be implemented as a service but may have
a function-call interface to P. We already have to deal with
service execution (something that is not well documented in P or
IRML yet) so we would not be adding much more complexity; we would
just need to document an interface where a service can return a
value for P interpreter to use.

Yes, I like that idea a lot. Conceptually, there is really not much
of a difference between a P module and an OPES service. But since we
are trying to define a framework for OPES services I think it makes
a lot of sense to provide functions such as isGIF or findVirus as
OPES services.  Plus, this would also allow an OPES domain
administrator to make a local decision as to whether a service like
isGIF should run locally on the OPES processor or on a remote
callout server. This should be transparent to P programs, of course.

I think if we decide to go down this route, then it would be a
natural choice to restrict P module access to message headers while
OPES services can access the entire message. Of course, a utility
service like isGIF would only need to see the first few bytes of the
message body and would therefore be less expensive to invoke than a
service that needs to operate on larger parts of the message body.
This could be one criteria that determines whether or not a service
is a good candidate for local execution.

I am glad we seem to be making progress here. It seems to me that if
we make service interface identical to a function call interface, then
there will be no reason to distinguish the two in P! It would be up to
the module writer and service provider to decide which way to go and
when. Thus, we "solve" the problem by offloading all these
optimization decisions to those who have more information at hand.

The question is, then, how we can make a service invocation to look
identical to a module method invocation from P user point of view?
There are many similarities here:

        - both modules and services need to be selected
          and "loaded" (imported) by a programmer

        - both module methods and services need to be
          executed

        - interface to get method execution results
          or service execution results is still
          undocumented

The difference is that a module may have many methods while service
is, essentially one method (perhaps complex). That is, a module may
have many entry points while the service has only one.

The remaining difference is a perception that a function call "returns
fast" while a service execution may "take a while". Clearly, this is
not a perception worth supporting explicitly because both assumptions
may not be true.

So, how about the following short-term approach? Use import command to
load both modules and services. State that P Core does not define how
loaded modules or services provide P interpreter with a list of their
available entry points (this is currently the case as well, but
services are not loaded the way modules do). Essentially, make no
distinction between a module and a service. Everything is a module.
Service is a module, usually with a single method.

Long-term, decide whether we should document either a one-for-all
"list-of-entry-points-with-their-profiles" interface or one possible
"list-of-entry-points-with-their-profiles" interface, as a separate
draft. Note that this interface is internal to P interpreter;
programmers do not need to be aware of it.

Will something like that work?

Alex.




<Prev in Thread] Current Thread [Next in Thread>