[Pvfs2-developers] Re: BMI TCP socket close for sock buf size

[Phil Carns]

Pete Wyckoff wrote:
> pcarns at wastedcycles.org 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