round 1: ndr on top of trans2

[Amin Azez]

I should also mention I need async calls, and that custom notifications
will likely come in useful.

I'm doing NDR over trans2 because I'm hoping that the rpc over trans2
problems are not actually trans2 problems.

Sam

* Amin Azez wrote, On 18/01/08 13:14:
> * Stefan (metze) Metzmacher wrote, On 18/01/08 12:03:
>> Amin Azez schrieb:
>>   
>>> It'll be a new day before I can test this, but taken that it works (or
>>> can be made to) is their anything architecturally offensive in it?
>>> Have I missed any useful use of params (which I ignore)?
>>>  
>>> smbcli_ndr_request_trans2_send() sends (or at least constructs right
>>> now) a trans2 smbcli_request based on an NDR representation produced by
>>> gen_ndr generated code, and packed directly onto the smbcli_request, to
>>> save tallocs and memcpy.
>>>     
>>
>> I think using ndr makes no sense here at all.
>>
>> It would really be help full to chat with you on
>> the irc channel (#samba-technical on freenode.net)
>> next week. I'm usually online from 8:00 to 16:00
>>   
> Your Date: header suggests that this would be at least vaguely
> european time. I'll hope to catch you then.
>> The more important thing is: what are the logical
>> operation and their input and output parameters.
>> Thinking about the transport layer should be a second
>> step.
>>   
> I need to add extra facilities to read operations to permit
> compression of responses, and the read request/response to make use of
> file deltas from a cache system; and similarly for write operations;
> or: I need read/write variants that have different and more arguments
> in both directions.
>
> And then I need further operations for general cache-engine
> synchronization.
>
> Transport progression (!) has gone like this:
>
> 1. abusing existing well defined operations (when the peer has the
> right capability set)
> 2. defining my own operations (to work similar to SMBREADX, but taking
> unused op-codes)
> 3. being told to use a trans2 subcode,
> 4. to being told to use DCERPC (before I had time to do 3)
> 5. being told DCERPC is not good for async (which puts me back to trans2)
>
> I really want a transport that preserves tid/mid/pid contexts anyway,
> so it ought to be (2) or (3).
>
> Why am I using NDR? Because looking, and samba notes, suggest that it
> will save packing and unpacking my data by hand, but use of NDR seems
> to be the mildest of concerns.
>
> I should probably try to avoid optimizing NDR over trans2 in the short
> term and just close my eyes to the copying of blobs.
>
> I'll try and catch you on IRC next week.
>
> Sam