[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]
RE: Server side or client side processing?
#I'm still working away at that Distributed File Sys project of
Gung ho ! keep going buddy !
#Reading the design docs of some of the other DFS's around, I
#many of them push as much processing as they can onto the
#client. In CODE
#for e.g. when the client writes to the server, it has to update all the
#servers with the latest copy of the file.
#I'm thinking of producing something that is geared towards really thin
#clients (phones / PDA's) which are operating under band-width
#In this case writing to all the servers would be tedious and
#slow. Why not
#write to one and let the servers update each other over the high speed
#backbone they're connected to?
MAkes sense in your case. Also, take intoconsideration taht _maybe_ a client
will not have access to all the servers but if there is a trust relationship
amongst all the servers then server synchronisation wshoould be a better
approach. We need to consider (also)
o the time taken for such stuff
o the frequency of sync(s)
o the load on the servers.
o Would the syncs lead to an inconsistent state in the filesystem,
if a sync fails halfway. What is the commit algo ?
#What's the opinion of the list? Would it be better to push
#the servers and let the admins worry about upgrading the hardware, or
#keeping as much as possible on the client?
Well, lets not pass the buck on to the sysads ;) there's not much they can
do if the organisation is cash strapped :)
#The point is that phones etc are getting smarter and faster
#and there are
#new standards comming in which should make bandwidht much more
what I feel is that a DFS should be plymoprhic . In the sense, it should
support fat and thin clients, depending upon the client configuration, which
is conveyed to at at the start of a session (overhead). However, these two
roles better be in tune with each other so that the filesys is in a