<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.6000.16525" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">
<DIV>just for a laugh, I've implemented so that the OGS Grid comms now
have a Local Grid comm, and forwards all requests to it to see if it can be
handled locally, if not, it accesses the grid.</DIV></BLOCKQUOTE>
<DIV><FONT face=Arial size=2></FONT><BR></DIV>
<DIV><FONT face=Arial size=2>One second thought, I think we should be very
carefull about the levels of indirections</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>The comms manager already has a lot, most of the
various base classes in the inheritance chain try to implement complex
logic, user simpler - and multiple - methods to the genric comms (be it the
local or the OGS one), when the comms layer needs database access you will again
see a lot of indirections.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>We have 2-3-4 different DB plugins (SQLLite and
MySQL probably being more complete and stable), If you examine both the MySql
and SQLite plugins, they are again staggered into a hierarchy of
logic.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>So if you tweak the local comms layer to attempt a
local access first, and then divert to OGS in case you fail, you
risk:</FONT></DIV>
<DIV><FONT face=Arial size=2>1) Duplicating the decision of wheter to uses local
or OGS in two different layers of the application</FONT></DIV>
<DIV><FONT face=Arial size=2>2) Introduce - atleast increased -latency in the
network communications, and that will cause the lag monster to
appear.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>I am pretty worried, we have a very flexible
engine, with a lot of dynamically loaded assemblies, which - atleast on
Microsoft - </FONT> <FONT face=Arial size=2>will produce less than optimum
compiled code, and we generally use a very inefficient network comms protocol
(XML-RPC and REST). How can we get that to perform well?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>I would suggest that we:</FONT></DIV>
<DIV><FONT face=Arial size=2>1) Use .NET remoting for all our communications,
out of the box .NET comes with TCP, HTTP and IPC channels. IPC is designed to be
a local machine interprocess communications protocol. </FONT><FONT
face=Arial size=2>TCP and HTTP should be pretty self explanatory. The format of
the messages can be controlled via formatters, out of the box .NET supports
binary and SOAP, but an XML-RPC formatter is freely available.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>2) Drop local mode.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>If we switch to a complete remoting based
communications protocol, it will be possible to use high performance IPC
remoting if we are running in stand alone mode, and stil delegate communications
on a per server basis via the config files.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>This way stand alone mode, is merely a question of
using the right configuration. The gains are that we reduce the comlexity of the
codebase by removing all the local comms stuff. and remove one layer of
abstraction.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>/Tleiades</FONT></DIV></BODY></HTML>