Re: RFCS (BIND image)

[Eddie Renoux <[e-mail]>]

> > >   ...Also why require the server to keep
> > >   a BIND-IMAGE around for each session -- just send it when the server
> > >   is going to positively respond to the BIND.
> >
> > I'm not sure I understand what you're getting at here.  By "keep a
> > BIND-IMAGE around for each session" do you mean for the entire life of a
> > given session?  The draft simply says that the server must send a copy of
> > the Bind image to the client as soon as an SNA session is established;
> > whether or not the server hangs on to a given session's associated Bind
> > image after that is, I suppose, up to the server.  Or am I missing your
> > point?
> >
> > Thanks,
> > Bill
>
> I think his point was that you have to hold the BIND-IMAGE around until the
> Start-Data-Traffic flows.  I suppose it means that the client cannot send
> data traffic to the server until the server can send that data to Vtam.  It
> is a tradeoff of whether to buffer the data traffic or to buffer the
 BIND-IMAGE.
> At least the BIND-IMAGE is of a known, finite size, compared to data traffic.
>
> Is that right Tom?
>
> Fred
>
I see no reason why the BIND cannot be sent to the client as soon as the server
 has decided it is acceptable.  In PU 2.0 it is my understanding that the
 Primary
LU is the first speaker.  Thus the Secondary LU (client) cannot send anything to
the host until it has rec'd the first message (and Change Direction) from the
host.  (I have been wrong before.)
Eddie Renoux    [e-mail]