SwazooPort

I am adding some logging facilities into the Swazoo HTTP server so I can
capture "interesting" requests, and also verify that responses are
exactly right.

As part of this, I found myself looking at the relationship between
HTTPServer, SiteIdentifier, Site, SwazooServer etc.

It seems to me that the idea is to have one HTTPServer instance for each
port to be listened on (defined (sort of) by a SiteIdentifier).  The
HTTP server then has a list of the sites it's responsible for.

I'd like to introduce a SwazooPort that explicitly represents this and
allows the HTTPServer to focus on HTTP serving.

The SwazooPort would know the SwazooServer it was working in the context
of (not hard as this is a singleton at the moment), the SiteIdentifier
that defines the particular port address it represents, the HTTPServer
that will be doing the work on the port, and a collection of sites
associated with the port.  As a side note, at present each Site has a
single "uriPattern" at the moment, and so is linked to a single port ...
but I don't see why a single site could not handle requests from
multiple ports.

Does anyone see any problems with this? :-)

BTW - I hope to see many of you at StS05!

Thanks,
        Bruce
--
Make the most of your skills - with OpenSkills
http://www.openskills.org/

Hi Bruce,

I'm bit late, sorry for that:)

Bruce Badger wrote:
> I am adding some logging facilities into the Swazoo HTTP server so I can
> capture "interesting" requests, and also verify that responses are
> exactly right.

I was thinking for a while to introduce logging too:) A full Apache like
logging into a logfile ...
>
> As part of this, I found myself looking at the relationship between
> HTTPServer, SiteIdentifier, Site, SwazooServer etc.
>
> It seems to me that the idea is to have one HTTPServer instance for each
> port to be listened on (defined (sort of) by a SiteIdentifier).  The
> HTTP server then has a list of the sites it's responsible for.

Yes, Swazoo support virtual sites, that is, more than one site on same
ip and port. Therefore we have many-to-many relationship between Sites
and HTTPServers. There is an instance of HTTPServer for each ip/port
combination and each HTTPServer can serve many Sites. Also Site can have
aliases, (alternative hostnames), therefore more than one HTTPServer can
serve one Site.

SiteIdentifiers identify hostname/ip/port combinations for this Site.
Site can have more than one SiteIdentifier, for aliases and also for SSL
serving. Usually Site serve at port 80 and also SSL at port 443.

SwazoServer is actually only container for both Sites and active
HTTPServers. Appropriate HTTPServer is instantiated and started
automatically after you start some site and stopped/removed when all
sites it serves are stopped. If all sites are stopped, then there is
noone HTTPServer instance anymore.

Main thing in Swazoo are therefore Sites. HTTPServers are "internal" and
you usually don't need to deal directly with them.

I think you don't need to do that because SiteIdentifiers are adequate
from my experience so far. I would rather somehow simplify url
resolution, which is hard to debug and this probably let you think about
introducing SwazoPort. But maybe I didn't understand you well. Can you
explain SwazooPort bit further. Maybe by example? Would you subclass
something, which instvars will have?

Best regards
Janko


>
> Does anyone see any problems with this? :-)
>
> BTW - I hope to see many of you at StS05!
>
> Thanks,
> Bruce

--
Janko Mivsek
Systems Architect
EraNova d.o.o.
Ljubljana, Slovenia
www.eranova.si
tel: +386 1 514 22 55
gsm: +386 31 674 565

Janko,

> I'm bit late, sorry for that:)

No worries - thanks for the response!

Will you be at StS05, BTW?  It would be great if you were so we could
spend some time talking about Swazoo.
> I was thinking for a while to introduce logging too:) A full Apache
> like  logging into a logfile ...

For now, I would like to capture two kinds of log information.  Once would
be the bytes as exchanged with the client, and the other would be a more
formatted representation of the requests/responses.
I'm hoping that the byte log can be used to capture and *replay* requests
- this so I can capture the nasty attacks we sometimes get on our
production systems and test out how I want to respond to them.
> Yes, Swazoo support virtual sites, that is, more than one site on same
> ip and port. ...

Thanks for the explanation.  I'm happy to say that you didn't surprise me
- phew! :-)
> Main thing in Swazoo are therefore Sites. HTTPServers are "internal"
> and  you usually don't need to deal directly with them.

Understood.

I guess, then, that I'm not really *using* Swazoo, as much as I am using
the Swazoo HTTP server.
What the SwazooPort does is to remove the need for the HTTPServer to have
a list of sites.  The HTTPServer now reads the socket, builds the request
object and then evaluates a block which is expected to take a request and
return a response.
After the introduction of the SwazooPort, when a Swazoo server is started
the SiteIdentifiers for each site are used to allocate each site to one or
more SwazooPorts.  The SwazooPort ends up with a collection of sites, some
of which may appear in more than one SwazooPort.  Each SwazooPort has a
single HTTPServer, and the response block for that server is set to do the
usual Swazoo "URIResolution resolveRequest: aRequest startingAt: self
sites" thing.
As it happens, the OpenSkills systems directly create the HTTPServer and
plug in their own response block.  From my POV, this simplifies getting
the HTTPRequest to my application logic.
>I would rather somehow simplify url  resolution, which is hard
>to debug and this probably let you think about  introducing SwazoPort.

I think there is some truth in this.  I think I found the Swazoo reolution
hard to understand when I first looked at Swazoo, and just put in the
simplest thing that would get a request to my code - a site that just
passed on the request.
One effect of introducing the SwazooPort is that the HTTP server is not
bound to the zoo and can be used by itself.
Of course, within the OpenSkills applications we have to resolve requests
to be able to have the right thing happen in response to a request.  We
have done this using the idea of Realms as used in the HTTP authentication
stuff.
>But maybe I didn't understand you well.

More likely I don't understand all the issues, and don't explain myself
well :-]
> Can you  explain SwazooPort bit further. Maybe by example? Would you
> subclass  something, which instvars will have?

I hope the above helps a bit.  Also, here is the comment from the
SwazooPort class:
"
A SwazooPort represents a specific ip address port combination, and the
set of Swazoo sites that are available through that port.
Instance Variables:
        parent <SwazooServert> This is the SwazooServer in whose context this
        Swazoo port exists. httpServer <HTTPServer> The HTTPServer that reads requests, and writes
        responses on this port. siteIdentifier <SiteIdentifier> Just contains the host and port number
        for this port (and the virtual host name) sites <Set of Site> This is the collection of sites which are available
        through this port"

I have implemented SwazooPort, and all the tests are fine.  It also does
allow me to directly plug in the OpenSkills application response blocks
into the HTTPServer - so from my POV, it's worked out well.
As an asside: I am also trying to follow your Store package layout and
have added the Swazoo-HTTP package that you have now.
I hope to see you at StS05.

All the best,
    Bruce