The short answer is no, there is no Get ( ) function that allows a client to return a list of all users who are logged in. To do so would be a security vulnerability.
The longer answer is that there are a few different methods you can use to get some control over this issue. Global fields are really not useful; they're user-specific and hence don't carry across to the server. However, you can use a Sessions table where each user creates a new record each time he logs in. If he should log in while he has an open session, then you know he has a previous session open.
Of course, as you note, this method has some issues, like network disconnects causing issues where the session is left "open" as far as the database is concerned. One way you can work around this is to track the persistent ID of the device being used to log in using Get ( PersistentID ). This allows you to determine that the new session is coming from the same device or workstation as the previous one, and therefore likely to be the same user (and not another user at another terminal). Such a method is more useful if users characteristically use the same devices to log in.
Another extra layer of checks can be provided by tracking the user's last activity and storing a timestamp in his Sessions record, along with the device ID. This will allow you to tell if the user is actually active on more than one device. If he's only active on one device, then you can have reasonable assurance that it's a timed-out session where he's not active.
However, none of this is foolproof. In order to get a truly good level of "protection", you would need to tap into either the server logs and parse them out to determine who's attached and who's not (nod to Wim DeCorte for this technique), or use the fmsadmin command-line tool and the associated LIST command to compare the logged-in users on some regular frequency (nod to David Jondreau). Either technique requires a bit more chops (mostly with batch files and server-side scheduling), but they are a little more reliable than trying to rely on working strictly inside FileMaker.
Although this is an old discussion, I have found a way to circumvent this problem. I have implemented a OTP system which sends the user associated with the login account an SMS containing an OTP. Unless the correct pin is entered, the application quits. This uses the HTTP_POST command provided by the Base Elements plugin and a paid for SMS service. This allows a script to interact with the API for the service. This solved most of the problems, except apparently where users are in close proximity to each other. In this case, the suggestions above may provide an additional layer of security.