Pete Wyckoff wrote:
[EMAIL PROTECTED] wrote on Mon, 17 Jul 2006 17:59 +0200:
I'm not sure that we really want to literally run client state machines
on the server. Most of them probably are probably not going to map
correctly to that environment (they store results in different places,
have different assumptions about who to contact, look for config values
in different places, etc.).
I think if one were doing server to server communication it would be
better to just implement new states that send requests (using
msgpairarray) where needed according to the server's assumptions. In
that case, a server would just be acting as a client in the request
protocol sense, rather than in the state machine sense. It would need
different code to handle the resonses etc.
I agree with what you're saying here, but have in mind one
particular use case where you wanted to design an IO forwarder that
uses the PVFS protocol on both sides. One (likely multi-threaded)
process would both act as a server to the "inside" clients, and
generate client requests aimed at "outside" servers. This kind of
usage blurs our usual definitions of what is a client and what is a
server.
I'm sort of hoping that we can abstract out some of these
assumptions so that parts of existing state machines could be used
on either the client or server. We can reuse things like
msgpairarray, as you point out, but perhaps there is a higher level
of functionality that could be shared too.
Ah, Ok. I wasn't thinking about it from the I/O forwarder perspective.
That definitely makes sense.
-Phil
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
