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, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/xrootd/xrootd","title":"xrootd/xrootd","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/xrootd/xrootd"}},"updates":{"snippets":[{"icon":"PERSON","message":"@abh3 in #673: The endsess indeed does terminate the prvios session as long as it's not \nstill executing in a plugin (the sever has no knowledge of the side-efects \nof terminating something outside of its scope). Part of termination is to \nclose the socket. My proposal was sto simply close the socket irrespective \nof where the session is executing. Since there is explicit ordering here, \nthat should solve this problem as the second open cannot occur before the \nfirst is either executed or thrown away. If the first is executed then the \nsecond is gauranteed to fail.\n\nAndy\n\nOn Wed, 21 Mar 2018, simonmichal wrote:\n\n\u003e @abh3 : could you put some light on how endsess is handled on the server side?\n\u003e\n\u003e 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.\n\u003e\n\u003e I noticed in the XrdXrootdProtocol::do_Endsess():\n\u003e ```\n\u003e // Extract out the FD and Instance from the session ID\n\u003e //\n\u003e sp = (XrdXrootdSessID *)Request.endsess.sessid;\n\u003e memcpy((void *)\u0026sessID.Pid, \u0026sp-\u003ePid, sizeof(sessID.Pid));\n\u003e memcpy((void *)\u0026sessID.FD, \u0026sp-\u003eFD, sizeof(sessID.FD));\n\u003e memcpy((void *)\u0026sessID.Inst, \u0026sp-\u003eInst, sizeof(sessID.Inst));\n\u003e\n\u003e // Trace this request\n\u003e //\n\u003e TRACEP(LOGIN, \"endsess \" \u003c\u003csessID.Pid \u003c\u003c':' \u003c\u003csessID.FD \u003c\u003c'.' \u003c\u003csessID.Inst);\n\u003e\n\u003e // If this session id does not refer to us, ignore the request\n\u003e //\n\u003e if (sessID.Pid != myPID) return Response.Send();\n\u003e\n\u003e // Terminate the indicated session, if possible. This could also be a self-termination.\n\u003e //\n\u003e if ((sessID.FD == 0 \u0026\u0026 sessID.Inst == 0)\n\u003e || !(rc = Link-\u003eTerminate(Link, sessID.FD, sessID.Inst))) return -1;\n\u003e ```\n\u003e and then further in XrdLink::Terminate(...):\n\u003e ```\n\u003e // We can now disable the link and schedule a close\n\u003e //\n\u003e snprintf(buff, sizeof(buff), \"ended by %s\", ID);\n\u003e buff[sizeof(buff)-1] = '\\0';\n\u003e lp-\u003ePoller-\u003eDisable(lp, buff);\n\u003e lp-\u003eopMutex.UnLock();\n\u003e\n\u003e // Now wait for the link to shutdown. This avoids lock problems.\n\u003e //\n\u003e if (killDone.Wait(int(killWait))) wTime += killWait;\n\u003e else wTime = -EPIPE;\n\u003e killDone.UnLock();\n\u003e ```\n\u003e\n\u003e 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?\n\u003e\n\u003e -- \n\u003e You are receiving this because you were mentioned.\n\u003e Reply to this email directly or view it on GitHub:\n\u003e https://github.com/xrootd/xrootd/issues/673#issuecomment-375007957\n"}],"action":{"name":"View Issue","url":"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