Jim,
thanks for the info.
Keeping it all in utf-8 makes sense as you say ... so long as you
don't need to access binary files directly with another app. If all
send/receive requests go through the sob it works fine ... I have one
service using it that way at the moment. Debating about whether to
switch it to using nproxy ... there's some sense in making it the
gateway for all requests for those files ... there are other systems
that use similar models e.g. email de-duping software i.e. the black
box service ... who knows how YouTube or AWS actually store the
data ... could be own propriety format for all I can know ... all I
see is what they present to me when I request an item.
Damien
On 28/10/2007, at 5:35 AM, Jim Davidson wrote:
Howdy,
I wrote the core SOB code years ago -- at the time I think our
goals included:
-- Security: Server connects out to known clients.
-- Performance: State-full connections, minimal protocol overhead,
lots of caching, no encoding overhead
-- Simple: String keys, string data, integration with net cache flush
-- Insight: Lot's of traffic counters collected
-- Tcl aware: Expects to store/send UTF-8 strings only
-- Some special case stuff, e.g., the comment board code.
In general, SOB met these goals at the expense of:
-- Config complexity: Maintaining topology is rationale but
tedious compared to client-server HTTP connections through routers
-- Binary: Just strings
-- File system scale: SOB relies on rationale topology and/or key
management to avoid file system scale problems (i.e., too many
files in a directory).
The point on UTF-8 deserves a bit more explanation. In general,
all the parts of the "dci" module assumed everything is in UTF-8,
always. In a sense, it's best to imagine SOB (and NV, AV, etc.) as
really just a way to serialize Tcl data to/from some stable
something -- if it's not in memory, it's designed to be read
directly into memory with no encoding / translation / etc. In
other words, the lack of encoding and binary code support was by
design, not an oversight, which provided some benefits but -- as in
the case of trying to use SOB for thumbnails -- some downside.
-Jim
On Oct 25, 2007, at 9:12 AM, Michael Andrews wrote:
In general, I find the SOB model works well. The caching on the
server and the client provide unmatched performance. The NCF
provides a mechanism to flush the cache on updates. The Devil is
always in the details. How you set up multiple SOB servers and
then get the publishes to multiple SOB servers can certainly
create scaling and topology management issues.
Most sites to do not have the demands that AOL has - and a simple
SOB solution would be nice addition to any content distribution
system. However there are advantages to stateless systems. :-)
(How's that for diplomatic)
M
On Oct 25, 2007, at 10:19 AM, Dossy Shiobara wrote:
On 2007.10.25, Jay Rohr <[EMAIL PROTECTED]> wrote:
In general, I would not recommend using sob. It was developed
for very
specific requirements at AOL and it does not scale well under
load -
volume or frequency. We are in the process of replacing it with
something else.
Okay, this is just plain misinformation. SOB works very well for
what
it was intended for, a low-write, high-read, distributed service for
small objects (thus, the name "SOB").
Any scaling issues AOL is having has to do with how it has since
been
misused and/or operationalized.
-- Dossy
--
Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave
the Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave
the Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
<[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
