[cad-linux-dev] push vs pull network architecture
- From: Eric Wilhelm <ewilhelm@xxxxxxxxxxxxx>
- To: cad-linux-dev@xxxxxxxxxxxxx
- Date: Sun, 4 Apr 2004 23:42:52 -0600
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.)
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.)
With a pull architecture, each client must continually ask the server if
anything has changed ("are we there yet?")
A pull architecture would certainly integrate better with the idea of "working
offline", and should require less attention from firewall admins, but has the
quality of "annoying" the server with too-frequent requests when the number
of clients gets large.
The push architecture gives the client better "real-time" status of the model,
but wouldn't work so well with regard to "working offline" and of course not
every client would have the luxury of having an internet-accessible IP
address.
Maybe something like a proxy-server setup? e.g. it really is a "push"
architecture, but with the ability to chain hosts together (like ftp
mirrors?)
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.)
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.)
Any thoughts / references on this sort of thing? What might be a good
protocol(s) to build on?
--Eric
--
"It is impossible to make anything foolproof because fools are so ingenious."
--Murphy's Second Corollary
Other related posts:
