View Full Version : Does pre-registering mess up g2g.IsClientAvailable?
Mastiff
January 27th, 2006, 06:31 AM
I'm trying to run an automated backup system, but I am stopped by something weird in the g2g.IsClientAvailable function. Here's the code I run:
if g2g.IsClientAvailable("192.168.0.7") == false
Sometimes, even after turning off the computer that's checked and restarting girder on the computer that's checking, the result will be that the checked computer is running! Any ideas would be appreciated.
Rob H
January 27th, 2006, 06:49 AM
What does
print(g2g.GetClientDetails("192.168.0.7")) show?
Mastiff
January 27th, 2006, 06:52 AM
no connection DVD-Server 192.168.0.7 20005 true
Rob H
January 27th, 2006, 09:48 AM
In that case you could use
if g2g.GetClientDetails("192.168.0.7") == 'no connection' then
Mastiff
January 27th, 2006, 09:54 AM
It seems like I can do that, yes! Thanks! :D
Mastiff
January 27th, 2006, 10:00 AM
Damn! No, I can't. It seems like if a client has been awake this run of Girder on the server, then it will be considered active for this code. I'm confused, but I think that's what's happening.
Mastiff
January 27th, 2006, 10:02 AM
Got it! If it has been there this run, it won't be "no connection", but "offline"! Then it seems that it works to use something like this:
if g2g.GetClientDetails("192.168.0.7") == 'no connection' or 'offline'
Rob H
January 27th, 2006, 10:22 AM
That won't work as it's equivalent to the one that I posted.
Try this :-
g2g.IsClientConnected = function(name)
local status = g2g.GetClientDetails(name)
return (status ~= nil) and (status == 'online')
end
Then you can use
g2g.IsClientConnected("192.168.0.7")
Mastiff
January 27th, 2006, 10:25 AM
In the meantime I have fixed it, by changing to this:
if g2g.GetClientDetails("192.168.0.7") == 'online'
So I have simply turned the logic around, and that seems to work.
JohnHind
January 27th, 2006, 12:23 PM
Hi Tor,
IsClientAvailable(...) is equivalent to (GetClientDetails(...) ~= 'offline').
If you pre-register a client, it has "not connected" status until a transaction is attempted and either succeeds or fails at which point it goes to "connected" or "offline".
It might be a good idea to do a ClientPing(...) on your pre-registered clients on startup to determine the correct status. You could even do a ClientPing every few minutes on a schedule event to ensure your machine always knows what is up and what down.
The technique you are using above solves the false positive problem, but it may not detect a client that IS available in all cases.
- John
Rob H
January 27th, 2006, 12:39 PM
I can't remember offhand what happens when you try to compare a string to nil. I think it throws an error. So my function would be safer in case you don't pre-register a server.
JohnHind
January 27th, 2006, 12:57 PM
Try
print(nil == 'john')
in the interactive console - it gives 'false' as expected. The important message here though is that for a pre-registered client, Girder does not know if it is on or off line until you've tried a transaction. Normally, without pre-registration, a client will not go into the table at all unless it responds to the comserv client discovery broadcast.
Rob H
January 27th, 2006, 01:59 PM
Right, understood
I've not used g2g yet, but out of interest how do you find out the result of a ClientPing(), or any other call for that matter.
Oh, one other minor point about the help files - you've said that several functions are depreciated, but I think you mean deprecated.
JohnHind
January 27th, 2006, 06:03 PM
The provided "high level transactions" all just succeed or fail, if they fail they change the status to "offline" and you can test this with IsClientAvailable. RunLua raises any Lua errors that occur in the Interactive Console as if they had been generated locally.
With the Low Level Transactions, you can supply functions to run when the response is received (or not) or even build complex chains and trees of transactions. Lua is a very nice language for this sort of thing!
deprecate - "express disapproval of"
depreciate - "lower the value or price of; disparage, belittle; fall in value."
Either seems to work OK in this context, though perhaps "supercede" would be better.
Mastiff
January 28th, 2006, 02:25 AM
Thanks, John, but I can't use the ping method since it takes some time before it gives up. I tried, but it could be delaeyd with up to 3 minutes, it seemed, and that won't work on this particular setup. As for checking on startup that's out of the question since the checking computer is on 24/7 while the chekced computer is on sometimes only a few minutes every day, but it's vital to the system to know if it is on.
In what cases wouldn't I detect a computer that's online in this method?
And does this mean that I'll have to change the whole setup to be 100 % reliable, like having the checked computer send a message to the checking computer every time it changes status - hibernates, resumes, shuts down, starts up and so on?
JohnHind
January 28th, 2006, 04:03 AM
Some of the mechanisms that g2g uses to tack clients online do not work in your case because your dual sub-net network defeats the broadcast client discovery method in comserv. Try this test in the g2g UI screen:
Start up Girder on the "always on" computer, you should see "not connected" as the status for all your pre-registered clients. Press the "Ping Clients" button - after a short time all the clients should show either "connected" or "offline". Now stop Girder on one of the "connected" clients. You should see that client go to "offline". Now start the client again. On my system, the client status goes to "not connected", but this depends on the broadcast mechanism. On yours, it will probably just sit at "offline".
If you are with me so far, please try this: on the CLIENT machine, go to the G2G UI and ping the always-on machine (if you have not already done so, you may need to pre-register it). Hopefully, this will bring the status for that client on the always-on machine to "not connected".
So far, this is all "science", if the experiment works we can move on to "engineering"!
Mastiff
January 28th, 2006, 08:55 AM
Nope, sorry. The client computer stays at offline on the always on computer, even if the always on computer is shown as online on the client computer.
JohnHind
January 28th, 2006, 11:04 AM
OK, sorry Tor, looks like I took that bit out thinking it was redundant. Give me a few hours and I'll get you a new version.
Do you preregister all of your machines on all of the others? My thinking here is that we can replace the missing broadcast responses by putting in code to broadcast a ping to all the other machines whenever Girder starts up on any machine. This will depend on the clients preregistering the always-on machine as well as it registering the clients. I'll leave you do do that, since as far as I know you are the only one with this problem, but I need to change G2G to respond to incomming connections by setting the outgoing connection status to "not-connected" if it is currently "offline".
Mastiff
January 28th, 2006, 11:10 AM
Yes, I preregister everything on every computer (also the always on) with the regular preregister command (after having wrapped them all in the Kom.C1 and so on format). I can't say I understood exactly what you meant, but I'll just wait.
JohnHind
January 28th, 2006, 03:23 PM
OK Tor, this one should pass the test outlined above.
If so, I'm suggesting you put a scripting action in the GML on all your machines:
g2g.Ping()
And trigger this action with a GirderOpen event.
The idea is that when a client Girder starts, it will broadcast a test ping to all other Girders in its pre-registration list. This will register them as either Offline or Connected on this machine and will also change the status of this client in the other Girders from Offline to Not Connected. This will make IsClientAvailable return a true picture of what is on and off line.
Good Luck!
- John
Mastiff
January 29th, 2006, 04:15 AM
Thanks, John! I'll try that tomorrow, when I'm in my home office again. One question: This is what I use now for every computer when I want to preregister:
if Kom then
return
end
Kom={}
require('Girder2Girder')
function Kom.C2(msg,pld1,pld2,pld3,pld4)
g2g.ClientSendEvent("192.168.0.2",msg,200,1,pld1,pld2,pld3,pld4)
end
g2g.ClientRegister("Jobbmaskin", "192.168.0.2", 20005, "password***")
Can I just put the g2g.Ping() command at the end of that script? Because I assume that using without a computer in the paranthesis is what will make it ping all preregistered computers, right?
JohnHind
January 29th, 2006, 06:08 AM
Yes Tor, assuming this script gets run at startup or script reset then adding g2g.Ping() after all the registrations should work just as well.
g2g.Ping() pings all clients in the table (pre-registered or auto-discovered) wheras g2g.ClientPing("myclient") pings a specific client. The same pattern works for SendEvent etc as well if you ever want to perform the same transaction on all clients.
Mastiff
January 29th, 2006, 06:26 AM
Wow! You mean I can send the CID info to all clients with only one command?! Would a function for that be something like this:
function Kom.CAll(msg,pld1,pld2,pld3,pld4)
g2g.ClientSendEvent(nil,msg,200,1,pld1,pld2,pld3,p ld4)
end
and be fired like this:
Kom.CAll("CID.Telefon", CID.Number,CID.Name,CID.Address,CID.Datering)
Rob H
January 29th, 2006, 07:54 AM
I think that would be g2g.SendEvent()
JohnHind
January 29th, 2006, 10:00 AM
Yes, and you also need to drop the first parameter, so:
function Kom.CAll(msg,pld1,pld2,pld3,pld4)
g2g.SendEvent(msg,200,1,pld1,pld2,pld3,pld4)
end
The general pattern is drop the "Client" from the name and the first parameter. It is all in the manual! I did it this way to be consistent with the NetRemote script.
Mastiff
January 29th, 2006, 12:33 PM
Thanks! I'll take a look at that as well tomorrow.
Powered by vBulletin® Version 4.2.0 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.