> Well, I would not run anything besides a Coda server on a machine.
> Why would you need a client there? Are you going to run web servers
> on the same machines as Coda servers, or run Coda servers on workstations?

	Web servers will have dedicated machines and be coda clients.  We will
have machines dedicated to being coda servers, but these will also have
some other duties, like a postgres server (which doesn't utilize coda),
and some various cron updates and things (which do utilize coda, hence
the need for a coda client).

> > Removing the conflict has fixed everything, but raises the question:
> It is a known issue, something for FAQ...
> It is hardly possible for a client and a server to guaranteedly
> have the same view on which transaction succeeded and which did not.
> In some situations a reintegrating client has to guess, and sometimes
> it is wrong.

	Sure, that makes sense, but in our environment there shouldn't be any
such question in the first place.  0 dropped packets...

> > of power.  Is there a way to make coda a little more tolerant so that it
> > doesn't slip into disconnected mode unless there's actually a
> > disconnection?  Our architecture is such that there should never be two
> 
> It is possible to influence to some degree, but never have it guaranteed.
> Or looking from another perspective, you do not want the clients to wait
> forever when a server goes down.

	True, but I'd be happy if it waited a second or two.  In the case where
the server and client are very well connected and neither goes down.  Is
there a parameter I can tune to make this a bit more flexible?  Is the
problem that the ping times are so low that any blip is outside the
percent margin of error or something?

> It looks surprising but it is the reality - you can get a conflict
> with one client and one server. Jan has improved it but still
> there is an area of uncertainty when either the network drops packets,
> or either the servers or the clients are slower than expected by the peer.

	Or there must be another scenario here since we do not have dropped
packets (the packets go out on the loopback device) and the cpu usage is
very low on the machine.

	Any tuning suggestions?  Configuration options?  Or some source code I
should be looking at?

-- 
Patrick Walsh
eSoft Incorporated
303.444.1600 x3350
http://www.esoft.com/