On 03/31/2016 05:39 PM, Alex Bligh wrote:
>
> On 1 Apr 2016, at 00:26, Eric Blake wrote:
>
>> Hmm. If OPT_LIST reports 0, that's okay; we'll send transmission flags
>> again later during OPT_EXPORT_NAME/OPT_SELECT. But if OPT_SELECT
>> reports 0, and then you negotiate
On 03/31/2016 01:34 PM, Alex Bligh wrote:
>
> On 31 Mar 2016, at 19:50, Eric Blake wrote:
>
>>> I'd also like to say "I'd like my offsets / lengths to be a multiple of 4k"
>>> so I can open O_DIRECT. Or at least say "can you cope with only offsets /
>>> lengths that are a
On 31 Mar 2016, at 19:50, Eric Blake wrote:
>> I'd also like to say "I'd like my offsets / lengths to be a multiple of 4k"
>> so I can open O_DIRECT. Or at least say "can you cope with only offsets /
>> lengths that are a multiple of 4k, as if so I can perform better". But
>>
On 03/31/2016 11:57 AM, Alex Bligh wrote:
> I know that in practice *lengths* > 2^31 are hardly ever used by any
> client, so I'd like to say "the maximum length you can send me is
> 2^31 - 1".
>> Large-file support on 32 bit architectures has existed since several
>> decades now. We should not
On 31 Mar 2016, at 18:05, Wouter Verhelst wrote:
Although I'm implementing a server at the moment where I'd like to
do just that with lengths in excess of 2^31.
>
> Why?
Because golang represents lengths to 'read' as 'int' which is platform
dependent 32 bit or 64 bit
On Thu, Mar 31, 2016 at 04:28:37PM +0100, Alex Bligh wrote:
> On 31 Mar 2016, at 15:51, Eric Blake wrote:
> >>> -The server replies with:
> >>> +[option #A1 - only replies with payload are affected]
> >>> +The simple reply message MUST be sent by the server in response to a
>
On Thu, Mar 31, 2016 at 07:44:29AM -0600, Eric Blake wrote:
> On 03/31/2016 02:19 AM, Wouter Verhelst wrote:
> > We're getting close.
> >
>
> >> +[option #A1 - only replies with payload are affected]
>
> >> +[option #A2 - enabling structured replies MAY affect all other commands]
>
> >>
On 31 Mar 2016, at 15:51, Eric Blake wrote:
>>> -The server replies with:
>>> +[option #A1 - only replies with payload are affected]
>>> +The simple reply message MUST be sent by the server in response to a
>>> +request that requires no data payload.
>>
>> Well that's
On 03/31/2016 05:23 AM, Alex Bligh wrote:
> Eric,
>
> We're getting there! I'm only going to comment on this one rather than
> the 'final form' patch, so we get this one right to start off with.
Agreed.
>
> On 31 Mar 2016, at 07:06, Eric Blake wrote:
>> ### Transmission
>>
On 03/31/2016 02:19 AM, Wouter Verhelst wrote:
> We're getting close.
>
>> +[option #A1 - only replies with payload are affected]
>> +[option #A2 - enabling structured replies MAY affect all other commands]
>> +[option #A3 - enabling structured replies MUST affect all commands]
>
> I still
Eric,
We're getting there! I'm only going to comment on this one rather than
the 'final form' patch, so we get this one right to start off with.
On 31 Mar 2016, at 07:06, Eric Blake wrote:
> ### Transmission
>
> There are two message types in the transmission phase: the
We're getting close.
On Thu, Mar 31, 2016 at 12:06:23AM -0600, Eric Blake wrote:
> - Reply message
> + Simple reply message
>
> -The server replies with:
> +[option #A1 - only replies with payload are affected]
> +The simple reply message MUST be sent by the server in response to a
>
The existing transmission phase protocol is difficult to sniff,
because correct interpretation of the server stream requires
context from the client stream (or risks false positives if
data payloads happen to contain the protocol magic numbers). It
also prohibits the ability to do efficient
13 matches
Mail list logo