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
>>
>>
