Hi Fabrizio,
Actually, we have a couple of problems with redefining the "prqlen" field.
The main one is forwarde/backward compatability. 1) Old servers must work
with new clients and old clients must work with new servers. Therefore, the
trailing field *must* stay as 32 bits. That means subdividing it. The best
way is 8-8-16 as I indicated. Additionally, 2) Leandro has already worked up
that particular change with his implementation of vectored reads. So, I
strongly insist that the field be subdivided as 8-8-16.
Andy
----- Original Message -----
From: "Fabrizio Furano" <[log in to unmask]>
To: "Andrew Hanushevsky" <[log in to unmask]>
Cc: "Xrootd Mailing List" <[log in to unmask]>; "Peter Elmer"
<[log in to unmask]>
Sent: Wednesday, June 28, 2006 1:54 AM
Subject: Re: kxr_bind again
> Hi Andy!
>
> I am very advanced in the first impl of the multistream client. I want
> only to summarize here the version of the bind/read req I am expecting:
>
> kxr_bind:
>
> Request Normal Response
>
> kXR_char streamid[2] kXR_char streamid[2]
> kXR_unt16 kXR_bind kXR_unt16 0
> kXR_char sessid[16] kXR_int32 2
> kXR_int32 0 kXR_unt16 substreamid
>
>
> kxr_read:
>
> honestly I don't realize if the structs you specified can generate
> misalignments in certain architectures. Also, I don't see the point in
> sparing 1 byte for such a relatively long request. I'd be more generous
> for the flags/path/prglen fields, just to keep consistent with all the
> other requests, which have a 32bit dlen field as last field in the req
> header. I'd keep that also to maintain a little more protocol
> backcompatibility. Anyway, here it is my version:
>
> Request Normal Response
>
> kXR_char streamid[2] kXR_char streamid[2]
> kXR_unt16 kXR_read kXR_unt16 status
> kXR_char fhandle[4] kXR_int32 dlen
>
> kXR_int64 roffset kXR_char data[dlen]
> kXR_int32 rlen
> kXR_int32 dlen
>
>
> kXR_unt32 flags
> kXR_unt32 path
> struct prqlist[prqlen]
>
> struct prqlist {
> kXR_char prhandle[4];
> kXR_int32 prlen;
> kXR_int64 proffset;
> };
>
>
> Where prqlen is the number of pre-read reqs. Hence the relationship:
>
> dlen = prqlen*sizeof(prqlist) + 2*sizeof(kXR_unt32)
>
> NOTE:
> - path = 0 means that the respone has to be sent through the main login
> stream
> - the value of path also denotes the substream where to send the data
> chunk requested in the req header
> - the client does not care about the substream which will carry the
> response to a read request. So the server is allowed not to honor the path
> field for any reason. The idea behind is that a bunch of substreams is
> considered internally as one mega-stream with individually selectable
> substreams.
> - I don't have any idea about the flags which we need. From my point of
> view we can also consider to drop that field.
>
>
>
> NOTE2:
>
> Today/tomorrow I will commit my code, which seems to start working. For
> now it does not deal with the kxr_read modifications. It includes the
> mods/additions to XProtocol.hh, so, if you have any change for that,
> please wait a bit until I commit, and then change that version, just to
> avoid confusion... Here is some more info:
>
> - if the multistream support is disabled, then the old sock code is used.
> The multistream support is implemented at low level in a subclass of
> XrdClientSock.
> - I did a test with multistream on but with only one stream and it seems
> to work OK. More news to come.
> - well, I cannot bind any test substream because there is no kxr_bind
> yet... so anything can happen when you implement it and try to run the
> advanced client... :-)
>
>
> What do you think?
> Bye!
>
> Fabrizio
>
>
>
>
>
> Andrew Hanushevsky wrote:
>> Hi Fabrizio,
>>
>> A quick response as I am on vacation right now. I was planning for the
>> server to return the substream ID and it will be an integer from 1 to n.
>> As for directing responses to a particular stream. Recall that all
>> requests go on the original login stream. The client directs which stream
>> is to be used for the response. Recall that we were going to modify the
>> read and write requests so that the stream ID could be inserted. This is
>> also compatible with vectored reads that Renee wants. The change is:
>>
>>> kXR_int32 prqlen
>>>
>>> to
>>>
>>> kXR_char flags
>>> kXR_char path
>>> kXR_unt16 prqlen
>>
>> in the read request and similarly for the right request (there is a 4
>> byte
>> reserved field there). Note that "path" is the substream ID and it is a
>> character field as the stream id will be 1 to 255 (actually much
>> smaller).
>> You may want to reflect that in the bind response.
>>
>> Notice that only read/write is multi-stream capable. All other requests
>> are always done on the login stream. It simplifies things very much.
>>
>> Andy
>>
>> On Wed, 21 Jun 2006, Fabrizio Furano wrote:
>>
>>> Hi Andy,
>>>
>>> I am working on the multistream support, and I choosed the second way
>>> I commented in the previous message. The server has to generate an
>>> integer which will identify univoquely that substream in the pool which
>>> belongs to a session. I recall to you that part of the prev message.
>>>
>>> The client does not expect a praticular way to generate that number.
>>> Even random is good, so you can do what you prefer. The client also will
>>> not care about the (sub)stream it will get a response from. The only
>>> important thing is that all the msgs belonging to a particular request
>>> (e.g. kxr_oksofar+kxr_ok) all go through the same substream. No matter
>>> which. Otherwise it's impossible to keep the ordering.
>>>
>>> So, if you want, a first server side version could also randomize the
>>> choice of the response socket. this would be fine, since at the moment
>>> the protocol has no way of requesting the server to send a response
>>> through a particular substream.
>>>
>>> Right now I only wrote the low level support for the multistream
>>> xfers, but I believe that also the client will randomize the choice of
>>> the substream where to send requests to. We'll see.
>>>
>>> Fabrizio
>>>
>>>
>>>
>>> -------- Original Message --------
>>> Subject: kxr_bind
>>> Date: Thu, 15 Jun 2006 11:25:52 +0200
>>> From: Fabrizio Furano <[log in to unmask]>
>>> To: Andrew Hanushevsky <[log in to unmask]>
>>>
>>> Hi Andy,
>>>
>>> following our recent discussions on the multistream xfer, I propose
>>> this change in the kxr_bind spec:
>>>
>>> Request Normal Response
>>>
>>> kXR_char streamid[2] kXR_char streamid[2]
>>> kXR_unt16 kXR_bind kXR_unt16 substreamid
>>> kXR_char sessid[16] kXR_int32 0
>>> kXR_int32 0
>>>
>>>
>
