[cad-linux-dev] Re: push vs pull network architecture
- From: Bruno Postle <bruno@xxxxxxxxxx>
- To: CAD linux development <cad-linux-dev@xxxxxxxxxxxxx>
- Date: Mon, 5 Apr 2004 13:34:36 +0100
On Sun 04-Apr-2004 at 11:42:52PM -0600, Eric Wilhelm wrote:
>
> If a geometry server is to maintain connections with multiple clients
> simultaneously, would it be better for the server to push the data to the
> clients, or for the clients to occasionally poll the server for changes? Two
> existing analogous technologies might be IMAP and HTML (corrections /
> clarifications welcome.)
IMAP is comparable, the client gets the subset of data it asked-for
and can request the server to supply notification of updates as they
happen - The client doesn't have to poll continuously.
> With a push architecture, the clients are basically servers (so maybe X is a
> better analogy?) which sit and listen for updates from the "controller"
> (keeper of the data.)
Like a multiplayer Quake setup.
> Possibly using a dual-channel approach, we could have all get/send traffic on
> one port, with the option to receive notifications on another port? (and
> these notifications could then also be relayed by the proxy server after it
> has fetched the updates.)
NFS is robust and fast, it supports locking etc.. - So long as you
restrict your data-channel requirements to filesystem semantics.
FAM works with NFS (it listens on another port as you suggest) so
you can have the server notify the client of changes without having
to poll.
> Seems that something like subversion or cvs would be appropriate here, since
> an unexpected update from the controller could mean lost work if what you
> were working on should have been a branch. This, of course, would be a pull
> architecture, with "working offline" as a natural capability (although pure
> cvs/svn means "working online" is actually impossible.)
The CVS/SVN method of working offline is a better fit with real
design methods. A lot of CAD time is really messing-about trying
ideas - Stuff that doesn't want to be shared.
It's comparable to writing software, I _could_ work on the same
set of files as the developer next to me, but it wouldn't be very
sane - We are happier working on local copies and committing the end
result of the work.
--
Bruno
Other related posts:
