Macromedia Flash Server - .bytes_out

Author

.bytes_out :: Problem

Simon Skrødal

2005-04-26, 7:45 am

Dear all,=20

Thanks for previous advise with regards to camera vs mic bandwidth.=20

My application is coming along nicely, but of course, there are always a =
few problems along the way.=20

The app is currently streaming pre-recorded flv's only, and, by =
interfacing with AMFPHP, I have implemented a logging service, which =
captures a range of information from the client and application objects =
on the server side.=20

When a client disconnects from the application (i.e. stops viewing the =
stream), this information is written to a mysql database, with the help =
of a php script, which is called from the main.asc script. A short =
snippet of the server-side code below:

application.onDisconnect =3D function (p_client)
{
// Get the client accumulated stats before we disconnect...
client_stats =3D p_client.getStats();
// Call the ** remote ** php function writeLog()
p_client.serv.writeLog(client_ip, app_name, stream_name, =
client_stats.bytes_in, client_stats.bytes_out, client_start_time, =
client_end_time);
}

-- As expected, details are written to the database table (below data is =
only a small section of what has been logged for illustrating my =
problem):

Stream Name BytesSent BytesReceived Connection Start =
Connection End=20
csm_video_100 0 14753 2005-04-21 16:00:14 =
2005-04-21 16:00:14=20
csm_audio_16 375 387391 2005-04-21 16:00:14 =
2005-04-21 16:02:43=20
csm_audio_16 256 282088 2005-04-21 16:03:10 =
2005-04-21 16:05:04=20
csm_video_100 1186 4300907739 2005-04-22 12:03:27 =
2005-04-22 12:12:34=20
csm_video_100 198 89946 2005-04-22 11:41:01 =
2005-04-22 11:41:03=20
csm_video_100 778 4003496 2005-04-21 17:07:02 =
2005-04-21 17:10:16=20
csm_audio_16 0 4294980588 2005-04-21 20:50:09 =
2005-04-21 21:07:32=20
csm_audio_16 267 3478931 2005-04-21 20:50:09 =
2005-04-21 21:24:55=20
csm_video_100 1599 39609572 2005-04-22 09:55:20 =
2005-04-22 10:41:31=20
csm_audio_16 196 57120 2005-04-22 11:33:53 =
2005-04-22 11:33:59=20
csm_video_100 198 4306732801 2005-04-22 12:03:27 =
2005-04-22 12:12:34=20
csm_audio_16 256 107451 2005-04-22 14:02:03 =
2005-04-22 14:02:31=20
csm_video_100 2369 6456450 2005-04-22 14:05:24 =
2005-04-22 14:17:22=20
csm_video_100 325 10887871 2005-04-22 14:05:24 =
2005-04-22 14:19:26=20

....hope formatting of the above won't be messed up when I send this =
thing...=20

NOW, to the point. You have seen how I capture the client data, using =
getStats() and then passing the constants to my php function writeLog(). =
What is interesting from the table above, is the RECEIVED field =
(bytes_out). Sometimes, a client is recorded as to have received over =
4GB of data from a 16kbps or 100kbps stream over a very short time span!

Most data appears as expected, so I don't understand how the bytes_out =
sometimes suggests such a tremendous amount of data. I am thinking that =
maybe the numbers are corrupted when passed onto the php script using =
AMFPHP, but I don't have the knowledge to investigate this any further =
at the moment.=20

Can anyone think of anything that might corrupt my data, if it is, in =
fact, corrupted at all? Maybe I am doing something wrong that you can =
easily spot?=20

Any help, thoughts, ideas, suggestions etc... would be highly =
appreciated.

Thanks for your time

Simon Skr=F8dal

=-----------------------------------------------------------
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

Frédéric v. Bochmann

2005-04-26, 5:45 pm

Just for the fun to create more problems.

Have you ever tried to compare the data sent/received at the server =
level
compared to the total of the data sent/received for each client that
connected?

I always get more data transmitted at the server level than the =
application
level. This is causing me honestly big problems at work, since they've =
been
spending quite a lot of time on me trying to figure out why sometimes at =
the
application level I just get about 20% of the data that is transmitted =
at
the server level.

Sincerely
Fredz./

PS: I'd love to have some demystification about all this bytes =
calculations
problems that FC has.

=20

-----Original Message-----
From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of Simon =
Skr=F8dal
Sent: April 26, 2005 12:32 AM
To: FlashComm Mailing List
Subject: [FlashComm] .bytes_out :: Problem

Dear all,=20

Thanks for previous advise with regards to camera vs mic bandwidth.=20

My application is coming along nicely, but of course, there are always a =
few
problems along the way.=20

The app is currently streaming pre-recorded flv's only, and, by =
interfacing
with AMFPHP, I have implemented a logging service, which captures a =
range of
information from the client and application objects on the server side.=20

When a client disconnects from the application (i.e. stops viewing the
stream), this information is written to a mysql database, with the help =
of a
PHP script, which is called from the main.asc script. A short snippet of =
the
server-side code below:

application.onDisconnect =3D function (p_client)
{
// Get the client accumulated stats before we disconnect...
client_stats =3D p_client.getStats();
// Call the ** remote ** php function writeLog()
p_client.serv.writeLog(client_ip, app_name, stream_name,
client_stats.bytes_in, client_stats.bytes_out, client_start_time,
client_end_time);
}

-- As expected, details are written to the database table (below data is
only a small section of what has been logged for illustrating my =
problem):

Stream Name BytesSent BytesReceived Connection Start =
Connection
End=20
csm_video_100 0 14753 2005-04-21 16:00:14 =
2005-04-21
16:00:14=20
csm_audio_16 375 387391 2005-04-21 16:00:14 =
2005-04-21
16:02:43=20
csm_audio_16 256 282088 2005-04-21 16:03:10 =
2005-04-21
16:05:04=20
csm_video_100 1186 4300907739 2005-04-22 12:03:27 =
2005-04-22
12:12:34=20
csm_video_100 198 89946 2005-04-22 11:41:01 =
2005-04-22
11:41:03=20
csm_video_100 778 4003496 2005-04-21 17:07:02 =
2005-04-21
17:10:16=20
csm_audio_16 0 4294980588 2005-04-21 20:50:09 =
2005-04-21
21:07:32=20
csm_audio_16 267 3478931 2005-04-21 20:50:09 =
2005-04-21
21:24:55=20
csm_video_100 1599 39609572 2005-04-22 09:55:20 =
2005-04-22
10:41:31=20
csm_audio_16 196 57120 2005-04-22 11:33:53 =
2005-04-22
11:33:59=20
csm_video_100 198 4306732801 2005-04-22 12:03:27 =
2005-04-22
12:12:34=20
csm_audio_16 256 107451 2005-04-22 14:02:03 =
2005-04-22
14:02:31=20
csm_video_100 2369 6456450 2005-04-22 14:05:24 =
2005-04-22
14:17:22=20
csm_video_100 325 10887871 2005-04-22 14:05:24 =
2005-04-22
14:19:26=20

....hope formatting of the above won't be messed up when I send this =
thing...

NOW, to the point. You have seen how I capture the client data, using
getStats() and then passing the constants to my php function writeLog().
What is interesting from the table above, is the RECEIVED field =
(bytes_out).
Sometimes, a client is recorded as to have received over 4GB of data =
from a
16kbps or 100kbps stream over a very short time span!

Most data appears as expected, so I don't understand how the bytes_out
sometimes suggests such a tremendous amount of data. I am thinking that
maybe the numbers are corrupted when passed onto the php script using
AMFPHP, but I don't have the knowledge to investigate this any further =
at
the moment.=20

Can anyone think of anything that might corrupt my data, if it is, in =
fact,
corrupted at all? Maybe I am doing something wrong that you can easily =
spot?

Any help, thoughts, ideas, suggestions etc... would be highly =
appreciated.

Thanks for your time

Wouter van Vliet / WEBclusive

2005-04-26, 5:45 pm

Hi Simon,

Funny, how ppl over the world tend to create the same things. I just=20
finished something that does the same thing, just a little different.=20
What I did was actually send only two parameters to my userLogout=20
function (that's what I called what you named 'writeLog'). The client=20
object (with any extra information to send added to it), and the result=20
of client.getStats(). This gave my AMF service all the information there=20
is to know about the client without any curruption of data.

Can't imagine your different-from-mine approach being the cause of your=20
bytedata curruption. And only the bytes_out - that's weird. Maybe you=20
can try the following steps to debug (these are basically general=20
debugging pointers):

* Put a trace on bytes_out just before you call the server
(maybe devide it by 1024 a couple of times, to make it more
obvious the value goes into the GB's)
* If that gives you values into the GB's, you know your problem is on
the FCS side
* Check any line that has a reference to bytes_out, and make sure
you're not adding, multiplying, deviding the value
* If you need to, just put in a couple of traces (include line number
in trace so you know which one you see in your logs)
* Now, if the value you're sending to AMFPHP never comes into the GB's,
your problem is at the AMF service side. Basically, do the same thing
over there as you'd do on the FCS side - but this time fopen() a file
and write debugging information to a file. Make sure the opened file
is writable by the apache (or IIS) process.

Hope this might help anything. And please report back to the list once=20
you've found the origin of the problem - I'm quite curious ;).

The 'stats-gatherer' I wrote also measures bandwidth per 'usage' of an=20
application - the start of a usage period being first client connect,=20
and then end being last client disconnect. In my first attempt, I just=20
did application.getStats() and wrote those byte-values to the database=20
(and some others, of course). After looking at the gathered data, I saw=20
that I made a supid mistake. As the appinstance isn't terminated=20
immediately after the last client disconnects, the bytes_in and=20
bytes_out from last usage period were added to the current one.

No, I'm not trying to point out how stupid I can act sometimes - but=20
perhaps this little story can prevent others from making the same=20
mistake. Might even be a little bit relevant to your problem, Simon.

Hope this'll be of any help to you.

Greetings,
Wouter

Simon Skr=F8dal wrote:
> Dear all,=20
>=20
> Thanks for previous advise with regards to camera vs mic bandwidth.=20
>=20
> My application is coming along nicely, but of course, there are always =
a few problems along the way.=20
>=20
> The app is currently streaming pre-recorded flv's only, and, by interfa=
cing with AMFPHP, I have implemented a logging service, which captures a =
range of information from the client and application objects on the serve=
r side.=20
>=20
> When a client disconnects from the application (i.e. stops viewing the =
stream), this information is written to a mysql database, with the help o=
f a php script, which is called from the main.asc script. A short snippet=
of the server-side code below:
>=20
> application.onDisconnect =3D function (p_client)
> {
> // Get the client accumulated stats before we disconnect...
> client_stats =3D p_client.getStats();
> // Call the ** remote ** php function writeLog()
> p_client.serv.writeLog(client_ip, app_name, stream_name, client_st=
ats.bytes_in, client_stats.bytes_out, client_start_time, client_end_time)=
;
> }
>=20
> -- As expected, details are written to the database table (below data i=
s only a small section of what has been logged for illustrating my proble=
m):
>=20
> Stream Name BytesSent BytesReceived Connection Start Connec=
tion End=20
> csm_video_100 0 14753 2005-04-21 16:00:14 2005-0=
4-21 16:00:14=20
> csm_audio_16 375 387391 2005-04-21 16:00:14 2005-0=
4-21 16:02:43=20
> csm_audio_16 256 282088 2005-04-21 16:03:10 2005-0=
4-21 16:05:04=20
> csm_video_100 1186 4300907739 2005-04-22 12:03:27 2005-0=
4-22 12:12:34=20
> csm_video_100 198 89946 2005-04-22 11:41:01 2005-0=
4-22 11:41:03=20
> csm_video_100 778 4003496 2005-04-21 17:07:02 2005-0=
4-21 17:10:16=20
> csm_audio_16 0 4294980588 2005-04-21 20:50:09 2005-0=
4-21 21:07:32=20
> csm_audio_16 267 3478931 2005-04-21 20:50:09 2005-0=
4-21 21:24:55=20
> csm_video_100 1599 39609572 2005-04-22 09:55:20 2005-0=
4-22 10:41:31=20
> csm_audio_16 196 57120 2005-04-22 11:33:53 2005-0=
4-22 11:33:59=20
> csm_video_100 198 4306732801 2005-04-22 12:03:27 2005-0=
4-22 12:12:34=20
> csm_audio_16 256 107451 2005-04-22 14:02:03 2005-0=
4-22 14:02:31=20
> csm_video_100 2369 6456450 2005-04-22 14:05:24 2005-0=
4-22 14:17:22=20
> csm_video_100 325 10887871 2005-04-22 14:05:24 2005-0=
4-22 14:19:26=20
>=20
>=20
> ...hope formatting of the above won't be messed up when I send this thi=
ng...=20
>=20
> NOW, to the point. You have seen how I capture the client data, using g=
etStats() and then passing the constants to my php function writeLog(). W=
hat is interesting from the table above, is the RECEIVED field (bytes_out=
). Sometimes, a client is recorded as to have received over 4GB of data f=
rom a 16kbps or 100kbps stream over a very short time span!
>=20
> Most data appears as expected, so I don't understand how the bytes_out =
sometimes suggests such a tremendous amount of data. I am thinking that m=
aybe the numbers are corrupted when passed onto the php script using AMFP=
HP, but I don't have the knowledge to investigate this any further at the=
moment.=20
>=20
> Can anyone think of anything that might corrupt my data, if it is, in f=
act, corrupted at all? Maybe I am doing something wrong that you can easi=
ly spot?=20
>=20
> Any help, thoughts, ideas, suggestions etc... would be highly appreciat=
ed.
>=20
> Thanks for your time

> Simon Skr=F8dal
>=20
> =3D---------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =3D---------------------------------------------------------
>=20
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>=20
>=20
>=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

Simon Skrødal

2005-04-26, 8:45 pm

Hi Fr=E9d=E9ric,

Based on my own (limited) experience with FCS, I'm not surprised to hear
about your findings. If there was only a small discrepancy between data
sent/received on server/client, it might have been explained by dropped
packets?

I just started reading the free 1st chapter of Brian's bible (will buy th=
e
whole thing very soon, I promise), and it mentioned how data is prioritis=
ed:

1. Audio
2. Actionscript
3. Video

** Disclaimer: This might be completely wrong, but...

Is it possible that when a user on dial-up connects to an application
pushing 256kbps (audio, video and data), FCS still pushes the whole 256kb=
ps,
but the dial-up user still only receives ~50kbps worth, primarily audio,
while dropping the rest? That could explain how sometimes you only receiv=
e
20% of the data at the client side. But then again, if this was the case,
you'd probably thought of it - besides, my assumptions about how FCS deal=
s
with this is probably wrong in the first place. Lucky I added that
disclaimer

Hopefully some of the more experienced on the list can shed some light on
this.

Good luck,
Simon

----- Original Message -----
From: "Fr=E9d=E9ric v. Bochmann" <fredericbochmann-rieW9WUcm8FFJ04o6PK0Fg@public.gmane.org>
To: "'FlashComm Mailing List'" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Wednesday, April 27, 2005 4:48 AM
Subject: RE: [FlashComm] .bytes_out :: Problem

Just for the fun to create more problems.

Have you ever tried to compare the data sent/received at the server level
compared to the total of the data sent/received for each client that
connected?

I always get more data transmitted at the server level than the applicati=
on
level. This is causing me honestly big problems at work, since they've be=
en
spending quite a lot of time on me trying to figure out why sometimes at =
the
application level I just get about 20% of the data that is transmitted at
the server level.

Sincerely
Fredz./

PS: I'd love to have some demystification about all this bytes calculatio=
ns
problems that FC has.

-----Original Message-----
From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of Simon Skr=F8=
dal
Sent: April 26, 2005 12:32 AM
To: FlashComm Mailing List
Subject: [FlashComm] .bytes_out :: Problem

Dear all,

Thanks for previous advise with regards to camera vs mic bandwidth.

My application is coming along nicely, but of course, there are always a =
few
problems along the way.

The app is currently streaming pre-recorded flv's only, and, by interfaci=
ng
with AMFPHP, I have implemented a logging service, which captures a range=
of
information from the client and application objects on the server side.

When a client disconnects from the application (i.e. stops viewing the
stream), this information is written to a mysql database, with the help o=
f a
PHP script, which is called from the main.asc script. A short snippet of =
the
server-side code below:

application.onDisconnect =3D function (p_client)
{
// Get the client accumulated stats before we disconnect...
client_stats =3D p_client.getStats();
// Call the ** remote ** php function writeLog()
p_client.serv.writeLog(client_ip, app_name, stream_name,
client_stats.bytes_in, client_stats.bytes_out, client_start_time,
client_end_time);
}

-- As expected, details are written to the database table (below data is
only a small section of what has been logged for illustrating my problem)=
:

Stream Name BytesSent BytesReceived Connection Start Connecti=
on
End
csm_video_100 0 14753 2005-04-21 16:00:14 2005-04-=
21
16:00:14
csm_audio_16 375 387391 2005-04-21 16:00:14 2005-04-=
21
16:02:43
csm_audio_16 256 282088 2005-04-21 16:03:10 2005-04-=
21
16:05:04
csm_video_100 1186 4300907739 2005-04-22 12:03:27 2005-04-=
22
12:12:34
csm_video_100 198 89946 2005-04-22 11:41:01 2005-04-=
22
11:41:03
csm_video_100 778 4003496 2005-04-21 17:07:02 2005-04-=
21
17:10:16
csm_audio_16 0 4294980588 2005-04-21 20:50:09 2005-04-=
21
21:07:32
csm_audio_16 267 3478931 2005-04-21 20:50:09 2005-04-=
21
21:24:55
csm_video_100 1599 39609572 2005-04-22 09:55:20 2005-04-=
22
10:41:31
csm_audio_16 196 57120 2005-04-22 11:33:53 2005-04-=
22
11:33:59
csm_video_100 198 4306732801 2005-04-22 12:03:27 2005-04-=
22
12:12:34
csm_audio_16 256 107451 2005-04-22 14:02:03 2005-04-=
22
14:02:31
csm_video_100 2369 6456450 2005-04-22 14:05:24 2005-04-=
22
14:17:22
csm_video_100 325 10887871 2005-04-22 14:05:24 2005-04-=
22
14:19:26

....hope formatting of the above won't be messed up when I send this thing=
....

NOW, to the point. You have seen how I capture the client data, using
getStats() and then passing the constants to my php function writeLog().
What is interesting from the table above, is the RECEIVED field (bytes_ou=
t).
Sometimes, a client is recorded as to have received over 4GB of data from=
a
16kbps or 100kbps stream over a very short time span!

Most data appears as expected, so I don't understand how the bytes_out
sometimes suggests such a tremendous amount of data. I am thinking that
maybe the numbers are corrupted when passed onto the php script using
AMFPHP, but I don't have the knowledge to investigate this any further at
the moment.

Can anyone think of anything that might corrupt my data, if it is, in fac=
t,
corrupted at all? Maybe I am doing something wrong that you can easily sp=
ot?

Any help, thoughts, ideas, suggestions etc... would be highly appreciated=
..

Thanks for your time

Simon Skr=F8dal

=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

=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

=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

Simon Skrødal

2005-04-26, 8:45 pm

Dear Wouter and Fr=E9d=E9ric (and everyone else),

Thanks for your suggestions and for sharing your own experiences with me =
and
others. Your application sounds very similar to mine indeed, Wouter

I guess I only gave half of the story in my last mail. My application
actually writes two logs as well, Wouter:
* One for each client that connects to watch a video (written on
application.onDisconnect),
* and another one (in a separate table) when the server side application
shuts down (written on application.onAppStop)
- This is similar to yours, Wouter, but I actually want it to report on=
ly
when the application automatically stops after a long time of idling, not
after the last client disconnects.

- As mentioned, the first log stores the .bytes_out value, retrieved from
each individual client's getStats(); function.

- The second log stores the .bytes_out value retrieved from
application.getStats() (along with other data, not relevant to this
problem).

Looking at the client log, .bytes_out sometimes reports as to have pushe=
d
over 4GB worth of data to a single client, watching a 16kbps stream for l=
ess
than 5 minutes. This is a ridiculous number, I know, but I am sure that i=
t
is not due to my incapacity in converting bytes to KB, MB, GB and so fort=
h.
Most records come up with reasonable numbers, you see. Only once in a whi=
le
(maybe 5%), a log entry throws these numbers at me.

....do you remember I mentioned the second log? The one that only records =
an
entry when the application stops/shuts down? Well, interestingly, this lo=
g
also gets the same humongous numbers, in accordance to the numbers added =
up
from clients. Some application log entries reports to have pushed 12GB, 8=
GB,
1GB worth of data. Keep in mind that these numbers derive directly from t=
he
bytes_out property of the application, while the client data is straight
from the bytes_out property of the client.

Something fishy is going on here. If the numbers are in fact true, I am a=
t a
loss. How would it be possible to push all that data in such a short
timeframe? And why doesn't the FCS lock up, since the bandwidth limit is
grossly exceeded?

Now, debugging. Yes, that's my next step, and I will have to get stuck in=
to
trace statements as soon as possible. I am still waiting to hear from my =
ISP
to find out how much load I have imposed on their bandwidth lately. Howev=
er,
I do not think there is any corruption of data being transmitted, and the
bytes_out data is not being tampered with before transmitting.

I will be sure to keep you up to date with my findings.

Thanks for your time,
Simon Skr=F8dal

----- Original Message -----
From: "Wouter van Vliet / WEBclusive" <wouter-cbyZFP1Q8NkXQ3Lr6voeyA@public.gmane.org>
To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Wednesday, April 27, 2005 6:50 AM
Subject: Re: [FlashComm] .bytes_out :: Problem

> Hi Simon,
>
> Funny, how ppl over the world tend to create the same things. I just
> finished something that does the same thing, just a little different.
> What I did was actually send only two parameters to my userLogout
> function (that's what I called what you named 'writeLog'). The client
> object (with any extra information to send added to it), and the result
> of client.getStats(). This gave my AMF service all the information ther=
e
> is to know about the client without any curruption of data.
>
> Can't imagine your different-from-mine approach being the cause of your
> bytedata curruption. And only the bytes_out - that's weird. Maybe you
> can try the following steps to debug (these are basically general
> debugging pointers):
>
> * Put a trace on bytes_out just before you call the server
> (maybe devide it by 1024 a couple of times, to make it more
> obvious the value goes into the GB's)
> * If that gives you values into the GB's, you know your problem is on
> the FCS side
> * Check any line that has a reference to bytes_out, and make sure
> you're not adding, multiplying, deviding the value
> * If you need to, just put in a couple of traces (include line number
> in trace so you know which one you see in your logs)
> * Now, if the value you're sending to AMFPHP never comes into the GB'=
s,
> your problem is at the AMF service side. Basically, do the same thi=
ng
> over there as you'd do on the FCS side - but this time fopen() a fi=
le
> and write debugging information to a file. Make sure the opened fil=
e
> is writable by the apache (or IIS) process.
>
> Hope this might help anything. And please report back to the list once
> you've found the origin of the problem - I'm quite curious ;).
>
> The 'stats-gatherer' I wrote also measures bandwidth per 'usage' of an
> application - the start of a usage period being first client connect,
> and then end being last client disconnect. In my first attempt, I just
> did application.getStats() and wrote those byte-values to the database
> (and some others, of course). After looking at the gathered data, I saw
> that I made a supid mistake. As the appinstance isn't terminated
> immediately after the last client disconnects, the bytes_in and
> bytes_out from last usage period were added to the current one.
>
> No, I'm not trying to point out how stupid I can act sometimes - but
> perhaps this little story can prevent others from making the same
> mistake. Might even be a little bit relevant to your problem, Simon.
>
> Hope this'll be of any help to you.
>
> Greetings,
> Wouter
>
> Simon Skr=F8dal wrote:
s a
few problems along the way.[vbcol=seagreen]
interfacing with AMFPHP, I have implemented a logging service, which
captures a range of information from the client and application objects o=
n
the server side.[vbcol=seagreen]
e
stream), this information is written to a mysql database, with the help o=
f a
PHP script, which is called from the main.asc script. A short snippet of =
the
server-side code below:[vbcol=seagreen]
client_stats.bytes_in, client_stats.bytes_out, client_start_time,
client_end_time);[vbcol=seagreen]
is
only a small section of what has been logged for illustrating my problem)=
:[vbcol=seagreen]
Connection End[vbcol=seagreen]
2005-04-21 16:00:14[vbcol=seagreen]
2005-04-21 16:02:43[vbcol=seagreen]
2005-04-21 16:05:04[vbcol=seagreen]
2005-04-22 12:12:34[vbcol=seagreen]
2005-04-22 11:41:03[vbcol=seagreen]
2005-04-21 17:10:16[vbcol=seagreen]
2005-04-21 21:07:32[vbcol=seagreen]
2005-04-21 21:24:55[vbcol=seagreen]
2005-04-22 10:41:31[vbcol=seagreen]
2005-04-22 11:33:59[vbcol=seagreen]
2005-04-22 12:12:34[vbcol=seagreen]
2005-04-22 14:02:31[vbcol=seagreen]
2005-04-22 14:17:22[vbcol=seagreen]
2005-04-22 14:19:26[vbcol=seagreen]
thing...[vbcol=seagreen]
getStats() and then passing the constants to my php function writeLog().
What is interesting from the table above, is the RECEIVED field (bytes_ou=
t).
Sometimes, a client is recorded as to have received over 4GB of data from=
a
16kbps or 100kbps stream over a very short time span![vbcol=seagreen]
t
sometimes suggests such a tremendous amount of data. I am thinking that
maybe the numbers are corrupted when passed onto the php script using
AMFPHP, but I don't have the knowledge to investigate this any further at
the moment.[vbcol=seagreen]
fact, corrupted at all? Maybe I am doing something wrong that you can eas=
ily
spot?[vbcol=seagreen]
appreciated.[vbcol=seagreen]
>
>
> =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
>

=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

Thijs Triemstra|Collab

2005-04-26, 8:45 pm

Hey Ive never managed to make a successful Remoting call in=20
application.onAppStop.. are you sure this one is working at all?

And=20=

is this win or linux? fcs 1.5.2 r138?

Thijs

Op 27-apr-05 om 3:01 heeft Simon Skr=F8dal het volgende geschreven:

> * and another one (in a separate table) when the server side=20
> application
> shuts down (written on application.onAppStop)=

=-----------------------------------------------------------
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

Simon Skrødal

2005-04-26, 8:45 pm

Thijs,

It's running on Linux, and it definitely works.

I am guessing/suggesting that you have not been able to get the onAppStop
working due to one or two reasons:

1. Keep in mind that onAppStop is not invoked if you use the Admin consol=
e
to unload your application
2. In my case, the onAppStop is only invoked when the application is
unloaded by the server, after x minutes of idle time - so to see some
results, you have to be patient

....I'm by no means an FCS guru, so if I can make successful remoting call=
s
on application.onAppStop, anyone can - just give it another go

Cheers,
Simon Skr=F8dal

----- Original Message -----
From: "Thijs Triemstra|Collab" <thijs-r6XmE1ReyPhmR6Xm/wNWPw@public.gmane.org>
To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Wednesday, April 27, 2005 10:37 AM
Subject: Re: [FlashComm] .bytes_out :: Problem

Hey Ive never managed to make a successful Remoting call in
application.onAppStop.. are you sure this one is working at all?

And
is this win or linux? fcs 1.5.2 r138?

Thijs

Op 27-apr-05 om 3:01 heeft Simon Skr=F8dal het volgende geschreven:

> * and another one (in a separate table) when the server side
> application
> shuts down (written on application.onAppStop)

=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

=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

Stefan Richter

2005-04-27, 7:45 am

Simon,
I really don't want to discourage your efforts but I have yet to see a =
100%
reliable logging system built in FCS using the admin api. I tried it =
myself,
it was a pain, it wasn't failover safe (imagine an external loggin app =
like
Flogger falling over) and in the end I gave up.=20
Even Macromedia failed at it (sorry David, your efforts are still much
appreciated) and any hosts I have been talking about seem to be logging =
at
router level or they don't share details about their own setup.

You are right that onappStop isn't invoked when you kill via the console =
and
IMO this adds to the frustration. Imagine an app having used several GBs =
of
data and for some reason you need to intervene and kill that app... If =
you
are logging via onAppStop then all that traffic will not be accounted =
for.

Stefan

> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org=20
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of=20
> Simon Skr=F8dal
> Sent: 27 April 2005 02:46
> To: FlashComm Mailing List
> Subject: Re: [FlashComm] .bytes_out :: Problem
>=20
> Thijs,
>=20
> It's running on Linux, and it definitely works.
>=20
> I am guessing/suggesting that you have not been able to get=20
> the onAppStop working due to one or two reasons:
>=20
> 1. Keep in mind that onAppStop is not invoked if you use the=20
> Admin console to unload your application 2. In my case, the=20
> onAppStop is only invoked when the application is unloaded by=20
> the server, after x minutes of idle time - so to see some=20
> results, you have to be patient

>=20
> ...I'm by no means an FCS guru, so if I can make successful=20
> remoting calls on application.onAppStop, anyone can - just=20
> give it another go

>=20
> Cheers,
> Simon Skr=F8dal
>=20
>=20
> ----- Original Message -----
> From: "Thijs Triemstra|Collab" <thijs-r6XmE1ReyPhmR6Xm/wNWPw@public.gmane.org>
> To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
> Sent: Wednesday, April 27, 2005 10:37 AM
> Subject: Re: [FlashComm] .bytes_out :: Problem
>=20
>=20
> Hey Ive never managed to make a successful Remoting call in=20
> application.onAppStop.. are you sure this one is working at=20
> all?

And is this win or linux? fcs 1.5.2 r138?
>=20
> Thijs
>=20
>=20
> Op 27-apr-05 om 3:01 heeft Simon Skr=F8dal het volgende geschreven:
>=20
>=20
> =3D---------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =3D---------------------------------------------------------
>=20
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>=20
>=20
> =3D-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =3D-----------------------------------------------------------
>=20
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>=20

=-----------------------------------------------------------
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

Thijs Triemstra|Collab

2005-04-27, 5:45 pm

Hey Simon,

Thanks for the suggestions because I tested the remoting/onAppStop with=20=

an application reload.. good to know it works when the application=20
instance is unloaded after the idle time.

Thanks,

Thijs

Op 27-apr-05 om 3:46 heeft Simon Skr=F8dal het volgende geschreven:

> Thijs,
>
> It's running on Linux, and it definitely works.
>
> I am guessing/suggesting that you have not been able to get the=20
> onAppStop
> working due to one or two reasons:
>
> 1. Keep in mind that onAppStop is not invoked if you use the Admin=20
> console
> to unload your application
> 2. In my case, the onAppStop is only invoked when the application is
> unloaded by the server, after x minutes of idle time - so to see some
> results, you have to be patient

>
> ...I'm by no means an FCS guru, so if I can make successful remoting=20=

> calls
> on application.onAppStop, anyone can - just give it another go

>
> Cheers,
> Simon Skr=F8dal
>
>
> ----- Original Message -----
> From: "Thijs Triemstra|Collab" <thijs-r6XmE1ReyPhmR6Xm/wNWPw@public.gmane.org>
> To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
> Sent: Wednesday, April 27, 2005 10:37 AM
> Subject: Re: [FlashComm] .bytes_out :: Problem
>
>
> Hey Ive never managed to make a successful Remoting call in
> application.onAppStop.. are you sure this one is working at all?

=
And
> is this win or linux? fcs 1.5.2 r138?
>
> Thijs
>
>
> Op 27-apr-05 om 3:01 heeft Simon Skr=F8dal het volgende geschreven:
>
>
> =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
>
>
> =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
>

=-----------------------------------------------------------
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

Simon Skrødal

2005-04-27, 8:45 pm

Hi Stefan,

You're not discouraging me at all, in fact, I'm probably even more motiva=
ted
to nail this thing

So far, aside from surprisingly high .bytes_out data returned from both
application and client, everything else about my FCS/AMFPHP/mySQL logging
feature seem to be very reliable. The fact that I am logging similar data=
at
both onAppDisconnect() and onAppStop(), gives me a way to measure any
discrepancies between the two, and if one fails, I can always fall back o=
n
data from the other.

I heard from my ISP, and he reported that there had been no unusual high
usage of outgoing bandwidth on my account lately, which means that the
reported 50GB or so of .bytes_out from FCS has to be, excuse my language,
bollocks. Not sure where to take it from here, but I will get to the bott=
om
of this somehow.

Thanks for the motivation, Stefan

Best Regards,
Simon Skr=F8dal

PS! Comments, however trivial or deep are highly appreciated.

----- Original Message -----
From: "Stefan Richter" <stefan-fMeCE+ULXElEfu+5ix1nRw@public.gmane.org>
To: "'FlashComm Mailing List'" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Wednesday, April 27, 2005 6:22 PM
Subject: RE: [FlashComm] .bytes_out :: Problem

Simon,
I really don't want to discourage your efforts but I have yet to see a 10=
0%
reliable logging system built in FCS using the admin api. I tried it myse=
lf,
it was a pain, it wasn't failover safe (imagine an external loggin app li=
ke
Flogger falling over) and in the end I gave up.
Even Macromedia failed at it (sorry David, your efforts are still much
appreciated) and any hosts I have been talking about seem to be logging a=
t
router level or they don't share details about their own setup.

You are right that onappStop isn't invoked when you kill via the console =
and
IMO this adds to the frustration. Imagine an app having used several GBs =
of
data and for some reason you need to intervene and kill that app... If yo=
u
are logging via onAppStop then all that traffic will not be accounted for=
..

Stefan

> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of
> Simon Skr=F8dal
> Sent: 27 April 2005 02:46
> To: FlashComm Mailing List
> Subject: Re: [FlashComm] .bytes_out :: Problem
>
> Thijs,
>
> It's running on Linux, and it definitely works.
>
> I am guessing/suggesting that you have not been able to get
> the onAppStop working due to one or two reasons:
>
> 1. Keep in mind that onAppStop is not invoked if you use the
> Admin console to unload your application 2. In my case, the
> onAppStop is only invoked when the application is unloaded by
> the server, after x minutes of idle time - so to see some
> results, you have to be patient

>
> ...I'm by no means an FCS guru, so if I can make successful
> remoting calls on application.onAppStop, anyone can - just
> give it another go

Simon Skrødal

2005-04-27, 8:45 pm

Hi Thijs,

I thought maybe that would be your problem.

It just so happened that I got that useful piece of information when read=
ing
the docs before I started writing my app. Had I not made a note of it the=
n,
I can imagine it would have ended up costing me a few hours of hair-pulli=
ng
frustration! So, if the FCS Gods are listening (not you, Brian, you just
wrote the Bible), I hope they acknowledge my appreciation for those lucky
little breaks I sometimes receive. Please give me a few more of those. Am=
en
;)

All the best,
Simon Skr=F8dal

----- Original Message -----
From: "Thijs Triemstra|Collab" <thijs-r6XmE1ReyPhmR6Xm/wNWPw@public.gmane.org>
To: "FlashComm Mailing List" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Wednesday, April 27, 2005 11:25 PM
Subject: Re: [FlashComm] .bytes_out :: Problem

Hey Simon,

Thanks for the suggestions because I tested the remoting/onAppStop with
an application reload.. good to know it works when the application
instance is unloaded after the idle time.

Thanks,

Thijs

Op 27-apr-05 om 3:46 heeft Simon Skr=F8dal het volgende geschreven:

> Thijs,
>
> It's running on Linux, and it definitely works.
>
> I am guessing/suggesting that you have not been able to get the
> onAppStop
> working due to one or two reasons:
>
> 1. Keep in mind that onAppStop is not invoked if you use the Admin
> console
> to unload your application
> 2. In my case, the onAppStop is only invoked when the application is
> unloaded by the server, after x minutes of idle time - so to see some
> results, you have to be patient

>
> ...I'm by no means an FCS guru, so if I can make successful remoting
> calls
> on application.onAppStop, anyone can - just give it another go

And
> is this win or linux? fcs 1.5.2 r138?
>
> Thijs
>
>
> Op 27-apr-05 om 3:01 heeft Simon Skr=F8dal het volgende geschreven:
>
>
> =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
>
>
> =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
>

=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

=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

Frédéric v. Bochmann

2005-04-28, 5:45 pm

Hey Simon,

I just thought of something. When I've been working on my fixed version =
of
David's Flogger ( http://flogger.is.dreaming.org/ ), I've encountered =
this
problem in my calculations. A very stupid mistake it was. I took the 2
subsequent measures and took the highest bytes_out and the lowest =
bytes_out
and did the difference, then added the next difference of the next 2
subsequent measures. This will give you a ridiculous number if your
application has restarted (or your server) since your measures on one of =
the
readings might get up to 500000000000 bytes and the second 0 bytes since =
the
counters are restarted. Don't know if your values you had pasted where
calculated or just stat values.=20
Anyways I hope it help you.

Fredz./

-----Original Message-----
From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of Simon =
Skr=F8dal
Sent: April 27, 2005 9:33 PM
To: FlashComm Mailing List
Subject: Re: [FlashComm] .bytes_out :: Problem

Hi Stefan,

You're not discouraging me at all, in fact, I'm probably even more =
motivated
to nail this thing

So far, aside from surprisingly high .bytes_out data returned from both
application and client, everything else about my FCS/AMFPHP/mySQL =
logging
feature seem to be very reliable. The fact that I am logging similar =
data at
both onAppDisconnect() and onAppStop(), gives me a way to measure any
discrepancies between the two, and if one fails, I can always fall back =
on
data from the other.

I heard from my ISP, and he reported that there had been no unusual high
usage of outgoing bandwidth on my account lately, which means that the
reported 50GB or so of .bytes_out from FCS has to be, excuse my =
language,
bollocks. Not sure where to take it from here, but I will get to the =
bottom
of this somehow.

Thanks for the motivation, Stefan

Best Regards,
Simon Skr=F8dal

PS! Comments, however trivial or deep are highly appreciated.

----- Original Message -----
From: "Stefan Richter" <stefan-fMeCE+ULXElEfu+5ix1nRw@public.gmane.org>
To: "'FlashComm Mailing List'" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Wednesday, April 27, 2005 6:22 PM
Subject: RE: [FlashComm] .bytes_out :: Problem

Simon,
I really don't want to discourage your efforts but I have yet to see a =
100%
reliable logging system built in FCS using the admin api. I tried it =
myself,
it was a pain, it wasn't failover safe (imagine an external loggin app =
like
Flogger falling over) and in the end I gave up.
Even Macromedia failed at it (sorry David, your efforts are still much
appreciated) and any hosts I have been talking about seem to be logging =
at
router level or they don't share details about their own setup.

You are right that onappStop isn't invoked when you kill via the console =
and
IMO this adds to the frustration. Imagine an app having used several GBs =
of
data and for some reason you need to intervene and kill that app... If =
you
are logging via onAppStop then all that traffic will not be accounted =
for.

Stefan

> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of
> Simon Skr=F8dal
> Sent: 27 April 2005 02:46
> To: FlashComm Mailing List
> Subject: Re: [FlashComm] .bytes_out :: Problem
>
> Thijs,
>
> It's running on Linux, and it definitely works.
>
> I am guessing/suggesting that you have not been able to get
> the onAppStop working due to one or two reasons:
>
> 1. Keep in mind that onAppStop is not invoked if you use the
> Admin console to unload your application 2. In my case, the
> onAppStop is only invoked when the application is unloaded by
> the server, after x minutes of idle time - so to see some
> results, you have to be patient

>
> ...I'm by no means an FCS guru, so if I can make successful
> remoting calls on application.onAppStop, anyone can - just
> give it another go

And is this win or linux? fcs 1.5.2 r138?
>
> Thijs
>
>
> Op 27-apr-05 om 3:01 heeft Simon Skr=F8dal het volgende geschreven:
>
>
> =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
>
>
> =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
>

=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

=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

=-----------------------------------------------------------
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

Simon Skrødal

2005-04-29, 2:45 am

Hey Fredz!

Thanks for that, although I am not 100% sure I understand what you mean..=
?

I did some more investigation yesterday, and slotted in a trace statement=
in
the server-side script, which outputs the .bytes_out value of a client on
disconnect. (A client being Peldi's FLVPlayer).

>From the trace, I was able to pinpoint when a high .bytes_out value is
returned. As it turns out, the FCS sometimes does not detect when the cli=
ent
(FLVPlayer) disconnects (application.onDisconnect()). I don't know if thi=
s
is an FLVPlayer or FCS issue. Nonetheless, when a client disconnection is
not registered, i.e. application.onDisconnect() is not executed, ALL
..bytes_out values for subsequent clients are 'corrupted' (incredibly high=
)
when they disconnect.

Here's the trace (I added comments to highlight interesting details):

// ********* TRACE START

App Reloaded // ********************* Reloadin=
g
the app from a previous run of several connections ******
Loading of app instance: riu/2005/ec/ags successful
Unloaded application instance riu/2005/ec/ags
Bytes Out: 17181605437 // ********************* 4 trace
statements originating from clients where onDisconnect() did not execute =
in
previous run ***
Bytes Out: 17181605437
Bytes Out: 17181605437
Bytes Out: 17181605437
***** running netserviceswrapper
***** running NetServices
***** running recordset
***** running RsDataProviderClass
onBWDone: kbitDown =3D 178, deltaDown=3D 273.32, deltaTime =3D 1.539, lat=
ency =3D
111KBytes 33.3642578125
New NetStream created (stream ID: 1).
Playing and resetting ags_video_100.
Started playing ags_video_100.
Bytes Out: 157572 // ********************* Client
disconnects: Sensible and believable number ******
NetServices info 1: writeLog_Result was received from server: true
who[NetServices] severity[info] number[1] meesage[writeLog_Result was
received from server: true]
onBWDone: kbitDown =3D 144, deltaDown=3D 273.32, deltaTime =3D 1.903, lat=
ency =3D
137KBytes 33.3642578125
New NetStream created (stream ID: 1).
Playing and resetting ags_video_100.
Started playing ags_video_100.
Bytes Out: 390883 // ********************* Client
disconnects: Sensible and believable number ******
NetServices info 1: writeLog_Result was received from server: true
who[NetServices] severity[info] number[1] meesage[writeLog_Result was
received from server: true]
onBWDone: kbitDown =3D 333, deltaDown=3D 273.32, deltaTime =3D 0.821, lat=
ency =3D
109KBytes 33.3642578125
New NetStream created (stream ID: 1).
Playing and resetting ags_video_100.
Started playing ags_video_100.
// ********************* HANG ON! THE APP ABOVE WAS SHUT DOWN, BUT IT NEV=
ER
REACHED application.onDisconnect()

onBWDone: kbitDown =3D 368, deltaDown=3D 273.32, deltaTime =3D 0.742, lat=
ency =3D
105KBytes 33.3642578125
New NetStream created (stream ID: 1).
Playing and resetting ags_video_100.
Started playing ags_video_100.
Bytes Out: 4295797840 // ********************* AND NOW, SUBSEQUENT APPS
OUTPUT RIDICULOUS bytes_out VALUES!! ******
NetServices info 1: writeLog_Result was received from server: true
who[NetServices] severity[info] number[1] meesage[writeLog_Result was
received from server: true]
onBWDone: kbitDown =3D 140, deltaDown=3D 273.32, deltaTime =3D 1.948, lat=
ency =3D
100KBytes 33.3642578125
New NetStream created (stream ID: 1).
Playing and resetting ags_video_100.
Started playing ags_video_100.
Bytes Out: 4295978450 // ********************* AND NOW, SUBSEQUENT APPS
OUTPUT RIDICULOUS bytes_out VALUES!! ******
NetServices info 1: writeLog_Result was received from server: true
who[NetServices] severity[info] number[1] meesage[writeLog_Result was
received from server: true]

// ********* TRACE END

....by this stage, there is now one client left 'hanging'. The player was
shut down, but that was not registered on the server-side. Because of thi=
s,
clients who gracefully disconnect will have an incorrect .bytes_out value=
..

I don't do anything to the .bytes_out value before it is traced. It is
lifted straight from Client.getStats():

application.onDisconnect =3D function (clientObj)
{
client_stats =3D clientObj.getStats();
trace(client_stats.bytes_out);
}

....so, yeah... the above function only executes 'sometimes'... and if it =
is
skipped once, all subsequent trace(client_stats.bytes_out) will output a
value of several gigabytes. Consequently, tracing the application's
..bytes_out, will also yield very high numbers. If I don't get to the bott=
om
of this, I think I might just go insane

Thanks in advance for reading this far!

Best regards,
Simon Skr=F8dal

----- Original Message -----
From: "Fr=E9d=E9ric v. Bochmann" <fredericbochmann-rieW9WUcm8FFJ04o6PK0Fg@public.gmane.org>
To: "'FlashComm Mailing List'" <flashcomm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org>
Sent: Friday, April 29, 2005 3:59 AM
Subject: RE: [FlashComm] .bytes_out :: Problem

Hey Simon,

I just thought of something. When I've been working on my fixed version o=
f
David's Flogger ( http://flogger.is.dreaming.org/ ), I've encountered thi=
s
problem in my calculations. A very stupid mistake it was. I took the 2
subsequent measures and took the highest bytes_out and the lowest bytes_o=
ut
and did the difference, then added the next difference of the next 2
subsequent measures. This will give you a ridiculous number if your
application has restarted (or your server) since your measures on one of =
the
readings might get up to 500000000000 bytes and the second 0 bytes since =
the
counters are restarted. Don't know if your values you had pasted where
calculated or just stat values.
Anyways I hope it help you.

Fredz./

-----Original Message-----
From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of Simon Skr=F8=
dal
Sent: April 27, 2005 9:33 PM
To: FlashComm Mailing List
Subject: Re: [FlashComm] .bytes_out :: Problem

Hi Stefan,

You're not discouraging me at all, in fact, I'm probably even more motiva=
ted
to nail this thing

>
> ...I'm by no means an FCS guru, so if I can make successful
> remoting calls on application.onAppStop, anyone can - just
> give it another go

And is this win or linux? fcs 1.5.2 r138?
>
> Thijs
>
>
> Op 27-apr-05 om 3:01 heeft Simon Skr=F8dal het volgende geschreven:
>
>
> =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
>
>
> =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
>

=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

=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

=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

=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