Bug 8138 - XDMCP sessions terminate when xdmcp clients suspend
Summary: XDMCP sessions terminate when xdmcp clients suspend
Status: RESOLVED INVALID
Alias: None
Product: xorg
Classification: Unclassified
Component: Protocol/Core (show other bugs)
Version: unspecified
Hardware: x86 (IA32) All
: low enhancement
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard: 2011BRB_Reviewed
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-05 13:36 UTC by Bernd Schubert
Modified: 2018-06-12 19:10 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Bernd Schubert 2006-09-05 13:36:33 UTC
I already sent this to gmane.comp.freedesktop.xorg (xorg@freedesktop.org?), but so far without an 
answer. So I'm filling a bug report.

Hi,

when I put an xdmcp client into APM suspend mode and it wakes up after some
time again, it doesn't get a connection to the xdmcp server any more.
We are using kdm as xdmcp server and client, but its seems to use xdm code
for the xdmcp protocol. 
I just put a client into apm suspend mode and monitored the server - the kdm
thread responsible for this client closed itself after a few minutes.

I just quickly looked through the xdmcp documentation, but I don't see any
reference that the manager (the xdmcp server, right?) is allowed to close
the session if there's no client. Only the display (so the xdmcp client)
may send KeepAlive request - so only the display is allowed to terminate a
session, isn't it?

Looking into the documentation again, the first section of chapter 6 says that the manager is 
allowed to close a connection, unfortunately there's not stated the condition:

6. Session Termination
When the session is over, the initial connection with the display (the one that acknowledges the
Manage packet) will be closed by the manager. If only a single session was active on the dis-
play, all other connections should be closed by the display and the display should be reset. If
multiple sessions are active simultaneously and the display can identify which connections belon
to the terminated sesssion, those connections should be closed. Otherwise, all connections shoul
be closed and the display reset only when all sessions have been terminated (that is, all initial
connections closed).

In session.c in ManageSession() the following loop will terminate the connection:

                for (;;) {
                    if (d->pingInterval) {
                        if (!Setjmp (pingTime)) {
                            (void) Signal (SIGALRM, catchAlrm);
                            (void) alarm (d->pingInterval * 60);
                            pid = wait ((waitType *) 0);
                            (void) alarm (0);
                        } else {
                            (void) alarm (0);
                            if (!PingServer (d, (Display *) NULL))
                                SessionPingFailed (d);
                        }

Clearly a server in standy or suspend mode can't answer ping requests. So I think there's somehow 
another solution required. 

Thanks,
Bernd
Comment 1 Samuel Thibault 2006-11-15 07:52:32 UTC
Something like the client should warn the server before suspending, so that the server increases the timeout? (yes, only increase: you probably don't want that suspended clients who crashed might let a server thread wait forever).
Comment 2 Daniel Stone 2007-02-27 01:33:26 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 3 Jeremy Huddleston Sequoia 2011-09-25 00:33:05 UTC
XDMCP was designed before one would expect a client to sleep (before APM really), so this is understandable.  This change will probably need a bump at the protocol layer for XDMCP as well as at-suspend handlers in the client to notify the server.

Either that or perhaps extending sleep proxy for your needs:
http://en.wikipedia.org/wiki/Apple_Sleep_Proxy_Service_%28Bonjour_Sleep_Proxy%29

TBH, this seems like more work than its worth.
Comment 4 Adam Jackson 2018-06-12 19:10:41 UTC
Mass closure: This bug has been untouched for more than six years, and is not
obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.