Print

---

The endsess indeed does terminate the prvios session as long as it's not 
still executing in a plugin (the sever has no knowledge of the side-efects 
of terminating something outside of its scope). Part of termination is to 
close the socket. My proposal was sto simply close the socket irrespective 
of where the session is executing. Since there is explicit ordering here, 
that should solve this problem as the second open cannot occur before the 
first is either executed or thrown away. If the first is executed then the 
second is gauranteed to fail.

Andy

On Wed, 21 Mar 2018, simonmichal wrote:

> @abh3 : could you put some light on how endsess is handled on the server side?
>
> On the client side when there is a stream timeout, the original connection gets closed, and then a new connection is opened. Once the connection is established a handshake happens, the last part of the handshake is the kXR_endsess request that is supposed to terminate the pre-existing connection. The "second open" from Steve/Eric's scenario is guaranteed to happen after the client receives the response to the kXR_endsess request.
>
> I noticed in the XrdXrootdProtocol::do_Endsess():
> ```
> // Extract out the FD and Instance from the session ID
> //
>   sp = (XrdXrootdSessID *)Request.endsess.sessid;
>   memcpy((void *)&sessID.Pid,  &sp->Pid,  sizeof(sessID.Pid));
>   memcpy((void *)&sessID.FD,   &sp->FD,   sizeof(sessID.FD));
>   memcpy((void *)&sessID.Inst, &sp->Inst, sizeof(sessID.Inst));
>
> // Trace this request
> //
>   TRACEP(LOGIN, "endsess " <<sessID.Pid <<':' <<sessID.FD <<'.' <<sessID.Inst);
>
> // If this session id does not refer to us, ignore the request
> //
>   if (sessID.Pid != myPID) return Response.Send();
>
> // Terminate the indicated session, if possible. This could also be a self-termination.
> //
>   if ((sessID.FD == 0 && sessID.Inst == 0)
>   ||  !(rc = Link->Terminate(Link, sessID.FD, sessID.Inst))) return -1;
> ```
> and then further in XrdLink::Terminate(...):
> ```
> // We can now disable the link and schedule a close
> //
>   snprintf(buff, sizeof(buff), "ended by %s", ID);
>   buff[sizeof(buff)-1] = '\0';
>   lp->Poller->Disable(lp, buff);
>   lp->opMutex.UnLock();
>
> // Now wait for the link to shutdown. This avoids lock problems.
> //
>   if (killDone.Wait(int(killWait))) wTime += killWait;
>      else wTime = -EPIPE;
>   killDone.UnLock();
> ```
>
> At a first glance it seems to me that the server will terminate the original connection while handling the kXR_endsess request. Could you comment on that?
>
> -- 
> You are receiving this because you were mentioned.
> Reply to this email directly or view it on GitHub:
> https://github.com/xrootd/xrootd/issues/673#issuecomment-375007957


-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/xrootd/xrootd/issues/673#issuecomment-375088690

########################################################################
Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1