| Author |
|
turbotime
Flashcom Newbie
Joined: 25 October 2006
Posts: 16
|
| Posted: 20 June 2007 at 18:20 | IP Logged
|
|
|
If im connected to fms and pull my LAN cable out of the computer, FMS still shows me as connected. Is there a way to detect this other than a heartbeat type check to all clients?
I have a heartbeat (setInterval) running that accounts for this but it seems like there should be some inherent FMS API that handles this....
|
| Back to Top |
|
| |
jbourne
Flashcom Middleweight
Joined: 03 March 2006
Posts: 81
|
| Posted: 20 June 2007 at 18:46 | IP Logged
|
|
|
I wish a solution for this existed. Our FMS dies every once in a while, and the only way to discover it is through a bunch of ghost connections (audio no longer plays, and all that happens is there's connects and disconnects without any activity). I've no idea how to watch for that, but I really wish I could. As it stands, I just cron a server restart nightly at 4am, but there's got to be a better solution :P
|
| Back to Top |
|
| |
turbotime
Flashcom Newbie
Joined: 25 October 2006
Posts: 16
|
| Posted: 20 June 2007 at 18:54 | IP Logged
|
|
|
yeah the way i do the less than graceful disconnects is like this:
setInterval call all clients "verifyConnected" when thecall is made i start a timer waiting for the reply also using a setInterval. When the reply is recieved the timerInterval gets reset, if the timerInterval reaches 5seconds, it can be assumed the client is no longer connected.
It works, and it works pretty well, but the issue is it doesnt account for network latency or general flash player latency. For instance if im running the debug player and have alot of trace on a frame the timerInterval will get to 2-3seconds before the response it sent back to the server, sometimes it will take even longer (>5s) and invalidly disconnect me. I could increase it to 10sec but that isnt a very good solution either !
Edited by turbotime on 20 June 2007 at 18:54
|
| Back to Top |
|
| |
jaycharles
Moderator
Joined: 18 February 2004
Posts: 507
|
| Posted: 20 June 2007 at 22:30 | IP Logged
|
|
|
I like to take a similar approach, but rather than call/response, I just have the client call a server side function that updates a timestamp variable in the client object (with no result object defined, and no reponse from the server side method).
Then, every X seconds, I run a server side function that loops through the client objects, and compares the client timestamp to the current timestamp. IF the client's timestamp is too old, I fire the onDisconnect for that client.
Hackish, ugly, and not at all the way I'd like it to be, but it works reliably.
|
| Back to Top |
|
| |
turbotime
Flashcom Newbie
Joined: 25 October 2006
Posts: 16
|
| Posted: 22 June 2007 at 01:57 | IP Logged
|
|
|
jaycharles,
thanks for the tip i actually switched my code to your model cause it seems more reliable when you think about it :)
I am in talks with adobe about fixing this bug- apparently fms will disconnect ghost connections on an interval, from my testing that interval is about 5min which is atrocious and the interval is NOT configurable [confirmed via adobe].
Whats worse is if you preform a client.ping() on a disconnected client it returns TRUE which is very confusing.
Hopefully my pestering adobe will get them to release a fix for this fairly serious issue, right now im talking directly with FMS engineers regarding this matter
Edited by turbotime on 22 June 2007 at 01:58
|
| Back to Top |
|
| |
Ultimate
Moderator
Super Flashcommer
Joined: 05 January 2004
Location: Canada
Posts: 1130
|
| Posted: 22 June 2007 at 04:05 | IP Logged
|
|
|
You're in talks with Adobe on fixing this? Wow.. I want your contact. I don't think there is a person on the FMS team that doesn't know about this bug and has know about it for years. Everybody pestered them and then gave up because there was really no response.
The main problem is that it's not so much a bug but a problem of the network. So, it's kinda hard to track down for them I think.
Hopefully they'll figure out something for v3, whenever it comes out.
__________________
Blog: http://www.sti-media.com
Community Site: http://www.FMSGuru.com
Game: Checkers
|
| Back to Top |
|
| |
jaycharles
Moderator
Joined: 18 February 2004
Posts: 507
|
| Posted: 22 June 2007 at 04:40 | IP Logged
|
|
|
Incidentally, I found that running garbage collection often gets rid of a lot of lost client objects.
I'm working on a project where we're using FME, and it takes FOREVER for FMS to realize FME is disconnected (not too sure why that is). The thing that sucks is, if FME drops the connection and FMS doesn't respond to it, when FME reconnects it can't publish to the same stream name.
I've had to resort to running GC once a second to get rid of the connections... but it seems to work. Whenever FME chokes (and it does that a lot), the client object is gone on the next GC.
Edited by jaycharles on 22 June 2007 at 04:43
|
| Back to Top |
|
| |
solisarg
Flashcom Middleweight
Joined: 30 October 2006
Location: Spain
Posts: 56
|
| Posted: 22 June 2007 at 14:41 | IP Logged
|
|
|
Interesting ... how do you run garbage collection explicitely?
Jorge
__________________
http://www.flash-db.com
|
| Back to Top |
|
| |
jaycharles
Moderator
Joined: 18 February 2004
Posts: 507
|
| Posted: 22 June 2007 at 18:18 | IP Logged
|
|
|
solisarg wrote:
Interesting ... how do you run garbage collection explicitely?
Jorge |
|
|
application.gc();
|
| Back to Top |
|
| |
jbourne
Flashcom Middleweight
Joined: 03 March 2006
Posts: 81
|
| Posted: 22 June 2007 at 19:28 | IP Logged
|
|
|
On the server side's main.asc or during the client app execution in the .fla code?
|
| Back to Top |
|
| |
turbotime
Flashcom Newbie
Joined: 25 October 2006
Posts: 16
|
| Posted: 24 June 2007 at 18:24 | IP Logged
|
|
|
probably just garbage collects in a setInterval right?
Just finished my sample client/server app that shows the client.ping() returning improper results, well see if it incites some change :crosses fingers: ill be sending it to adobe first thing tomorrow :)
|
| Back to Top |
|
| |
turbotime
Flashcom Newbie
Joined: 25 October 2006
Posts: 16
|
| Posted: 26 June 2007 at 16:04 | IP Logged
|
|
|
ok well ive sent the app to all the right people now im just waiting to see what adobe thinks of the issue... for all of those interested here is a link to the app/client so you can see how client.ping() fails to return the proper results if you disconnect the LAN cable from one of the connected clients, check it out:
pingTest Application
Edited by turbotime on 26 June 2007 at 16:05
|
| Back to Top |
|
| |
flashjockey
Flashcom Badass
Joined: 23 January 2004
Location: United States
Posts: 455
|
| Posted: 26 June 2007 at 18:52 | IP Logged
|
|
|
This problem should be resolved in the next release of FMS.
__________________
Brad Outlaw
Flash Media+ Team
Adobe Systems Inc.
Disclaimer:
My posts are my own and do not necessarily reflect the views, opinions,
strategies or advice of Adobe Systems or its affiliates.
|
| Back to Top |
|
| |
turbotime
Flashcom Newbie
Joined: 25 October 2006
Posts: 16
|
| Posted: 26 June 2007 at 19:46 | IP Logged
|
|
|
|
| Back to Top |
|
| |
stoem
Big Kahuna
stoem == Stefan
Joined: 05 January 2004
Location: United Kingdom
Posts: 1079
|
| Posted: 18 May 2009 at 10:30 | IP Logged
|
|
|
Hi Brad,
what's the latest on this? Have any improvements been made in recent releases?
Cheers
Stefan
__________________
Flashcomguru.com
|
| Back to Top |
|
| |
flashjockey
Flashcom Badass
Joined: 23 January 2004
Location: United States
Posts: 455
|
| Posted: 18 May 2009 at 21:57 | IP Logged
|
|
|
It goes without saying that many developers want that instant gratification when a user truly disconnects. However, there are several factors that play into the equation... some of those are within FMS's control, some out of FMS's control. I'll try and break it up into various options and layers.
At a very low level, FMS is bound by the network layer of the OS it's running on. Some OS's are better about gc'ing disconnected connections than others. There's also the hard disconnect that has to be factored in here (i.e. when someone yanks the network cable). The server, by proxy of the OS layer, still recognizes the connection. There's timeouts involved, etc.... Even in the Flash Player, you'll notice that it takes several seconds from the time a network is severed until you get the NetConnection.Connect.Closed event.
By default, FMS runs garbage collection on the application resources every 1 minutes. This is already set to the minimum value (in Vhost.xml). This process will clean up anything marked for GC within the app. There's also a "gc" method on the "application" class that you can call from within your application.
At a more granular level, there's the Auto Close Idle Clients feature which will automatically disconnect idle connections. Off the top of my head, I don't recall what the minimum values are for this are. In short, it runs a process every XX seconds, to disconnect clients who have been idle for YY seconds. This should work for many scenarios but isn't practical for others (such as browser not releasing an instance of FP that regularly interacts with FMS).
If you want to get even more granular, you can implement timers that regularly check timestamp differentials or ping the clients. For example: the client application regularly calls a server-side method, which in turn writes a timestamp associated with the client obj. The server app runs a process on interval that diffs the timestamps of the clients with current time. Any clients older than x seconds gets force disconnected. There's also the method of looping through the clients array, calling ping on the client object, and then running the application.gc when that's done. I can't attest to how well this works in larger scaled applications. I've found, at times, the scripting engine can be fussy with aggressive loops.
The use cases vary from app to app. In some of my own apps where I enforce unique user names, I find that simply performing a lookup and pinging the client, if exists, is sufficient.
Even with a hybrid of the afore mentioned options; at the end of the day, obtaining the holy grail of disconnects still relies on factors outside of FMS's control (@see paragraph 2).
__________________
Brad Outlaw
Flash Media+ Team
Adobe Systems Inc.
Disclaimer:
My posts are my own and do not necessarily reflect the views, opinions,
strategies or advice of Adobe Systems or its affiliates.
|
| Back to Top |
|
| |
Topic: Detecting ungraceful disconnects?
