negotiating caching options

[Amin Azez]

Some caching setups will be best managed by two CIF's proxies

[client]---[proxy]-----big-bad-internet---[proxy]---[server]

with the proxies negotiating extra caching and compression options.

We could have a private protocol between the two proxies and make a
distributed proxy but I figure they may as well use SMB between them and
benefit from kerberos and everything else involved, besides the
server-side proxy is optional for some kinds of optimization anyway...

...so.... I'm looking to create some new SMB messages - whats safe?

I'm reading that most excellent reference "Implementing CIFS", so my
first idea is to use a protocol header which is not 0xff S M B

but there may be some good reasons why I should not do this, perhaps it
would drop the session?

Perhaps I should do it with the negprot response data?
Or some control pipe endpoint thingies? (may favourite choice but will
it require a new tree-connect)?
or IPC$ ?
Or another command in the SMB protocol?
Steal a command of my own which I will use based on protocol negotation
to see if I am talking to another magic cifs proxy?

BTW I will want to manage cache-invalidation by a mix of:
1. op-locks being broken
2. directory change notification
3. promoting oplocks to batch-oplocks (?)

If (2) isn't supported in the server (surely not these days, anwhere
someone will want caching smb they will also have a decent server?)
maybe I could not quite close files so I can still get the op-lock
breakage? (don't beat me!)

it doesn't look like there are any spare flags..


I'll keep reading...

Sam