|
Home > Archive > Macromedia Flash Server > December 2005 > Parameters for surviving network hiccups
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Parameters for surviving network hiccups
|
|
| Jonathan Kaye 2005-12-22, 5:45 pm |
| This is a fairly broad question since I don't know where to pinpoint my
search.
I have a FlashCom-based program that some clients are running in a wireless
network environment. The sessions typically run less than 1 hour. I try to
tune the network to minimize disruptions, but occasionally some of the
participant connections will get dropped. I find that if I'm in the wired
environment, this happens much more rarely.
Is there a set of FlashCom parameters that I can adjust to try to maximize
reliability and to tell the server to extend the amount of time it waits
before dropping a connection?
Thanks!
-jonathan
Jonathan Kaye, PhD
President, Equipment Simulations LLC
www.EqSim.com / www.CommandSim.com / www.FlashSim.com
(888) 511-2452
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Beto A 2005-12-23, 5:45 pm |
| this is an issue that most face with <modem connections. The ways to fix=
this vary and identifying what is going on is not a simple task. What h=
as worked for me is simply having the server disconnect the user if a cal=
l doesn't get a response. Then on the client if a call is not recieved o=
ver a setinterval of time then it will prompt that the connection is down=
..=20
=20
I believe that FCS/FMS has its own checking system but if the OS holds=
the socket for an extended period of time you will need to do something =
like the above or modifications on the way your server handles socket dis=
connects.
=20
hope this helps
Beto
Jonathan Kaye <jmk-r/Lqbj3T0c8AvxtiuMwx3w@public.gmane.org> wrote:
This is a fairly broad question since I don't know where to pinpoint my
search.
I have a FlashCom-based program that some clients are running in a wirele=
ss
network environment. The sessions typically run less than 1 hour. I try t=
o
tune the network to minimize disruptions, but occasionally some of the
participant connections will get dropped. I find that if I'm in the wired
environment, this happens much more rarely.
Is there a set of FlashCom parameters that I can adjust to try to maximiz=
e
reliability and to tell the server to extend the amount of time it waits
before dropping a connection?
Thanks!
-jonathan
Jonathan Kaye, PhD
President, Equipment Simulations LLC
www.EqSim.com / www.CommandSim.com / www.FlashSim.com
(888) 511-2452=20
=3D-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=3D-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=20
=09
---------------------------------
Yahoo! DSL Something to write home about. Just $16.99/mo. or less
=3D-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=3D-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Brian Lesser 2005-12-23, 5:45 pm |
| One point underlined by Beto's note is that network connections are
simply lost and have to be reestablished. Therefore your client-side
code must sense if it has lost a connection and attempt to reconnect. On
the server-side it is possible that the reconnection attempt will arrive
before the server realises it has lost the client connection or perhaps
before it has cleaned up the lost client. In that case handling a
reconnection attempt requires a little more work. For example on the
server: retesting the original client connection, cleaning it up, and
accepting the new connection request. However, many systems only allow
one connection so more work is required to insure that only one valid
connection exists at a time.
Cheers,
-B
Beto A wrote:
>this is an issue that most face with <modem connections. The ways to fix this vary and identifying what is going on is not a simple task. What has worked for me is simply having the server disconnect the user if a call doesn't get a response. Then on
the client if a call is not recieved over a setinterval of time then it will prompt that the connection is down.
>
> I believe that FCS/FMS has its own checking system but if the OS holds the socket for an extended period of time you will need to do something like the above or modifications on the way your server handles socket disconnects.
>
>
> hope this helps
> Beto
>Jonathan Kaye <jmk-r/Lqbj3T0c8AvxtiuMwx3w@public.gmane.org> wrote:
> This is a fairly broad question since I don't know where to pinpoint my
>search.
>
>I have a FlashCom-based program that some clients are running in a wireless
>network environment. The sessions typically run less than 1 hour. I try to
>tune the network to minimize disruptions, but occasionally some of the
>participant connections will get dropped. I find that if I'm in the wired
>environment, this happens much more rarely.
>
>Is there a set of FlashCom parameters that I can adjust to try to maximize
>reliability and to tell the server to extend the amount of time it waits
>before dropping a connection?
>
>Thanks!
>
>-jonathan
>
>Jonathan Kaye, PhD
>President, Equipment Simulations LLC
>www.EqSim.com / www.CommandSim.com / www.FlashSim.com
>(888) 511-2452
>
>
>
>
--
________________________________________
______________________________
Brian Lesser
Assistant Director, Teaching and Technology Support
Computing and Communications Services
Ryerson University
350 Victoria St.
Toronto, Ontario Phone: (416) 979-5000 ext. 6835
M5B 2K3 Fax: (416) 979-5220
Office: AB48D E-mail: blesser-6s6ziW1YCwCw5LPnMra/2Q@public.gmane.org
(Enter through LB66) Web: http://www.ryerson.ca/~blesser
________________________________________
______________________________
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
|
|
|
|
|