|
Home > Archive > Macromedia Flash Server > December 2005 > How to link between internal IDs and SS Client /
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 |
How to link between internal IDs and SS Client /
|
|
| lti-1a8g-LMbKfuCQv7pBDgjK7y7TUQ@public.gmane.o 2005-12-14, 8:45 pm |
| Hi,
I'm trying to use efficiently the different convenient methods provided
on the server side : getUserStats, getLiveStreamStats, and so on.
The idea is to be able, whenenever a client disconnect or stops reading
a live stream, to be able to know for how long he played the live stream.
getLiveStreamStats ( proto: getLiveStreamStats(|/app_instance/|,
|/stream_name/|) ) returns an object with two properties :
-----------------quote-----------------------------------------------
+ publisher, Object; publisher statistics. The object has the
following properties:
* |name|: String; the name of the published live stream.
* |time|: Date object; time that the stream was published.
This property is a duplicate of |publish_time| and exists for backwards
compatibility.
* |type|: String; the type of stream for the publisher. The
value is |"publishing"|.
* |client|: Number; the client ID of the publisher.
* |stream_id|: Number; the stream ID of the publisher.
* |publish_time|: Date object; time that the stream was
published.
* |client_type|: String; the string type of the publishing
client.
* |publish_time|: Date object; time that the stream was
published.
+ subscribers, Array of subscriber statistics. The array contains a
|subscriber| property that is an object containing the following properties:
* |client|: Number; user ID.|
* subscribe_time|: Date object; the time that the user subscribed
to the stream.
-----------------quote-----------------------------------------------
Here's the problem : how to link between a server side Client object,
with all the interesting properties (agent, ip, referrer, etc...) and
its Client ID ?
Of course, if in "Programming FCS", and on many tutorials, there is info
on "how to generate a unique client ID", may'be the answer is just :
there isn't, but damn! it's so stupid. And it looks like it has not been
*fixed* in FMS 2.
When I see what Speedera has achieved, I wonder if they :
a) paid extra bucks to get a decent documentation
b) paid extra bucks to get Macromedia to build a specific version of FCS
c) reverse engineered FCS and added the functionnalities themselves.
PS: <rant time> Considering my past monthes' recurrent problems on
Speedera network, a) & c) are highly improbable. Or the people who
build the Speedera solution died in a plane crash. Or get fired monthes ago.
I'm highly supportive to the ahem ... two ? people left which looks like
they know something about the infrastructure of their services.</rant time>
=-----------------------------------------------------------
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
| |
| Brian Lesser 2005-12-15, 2:45 am |
| FWIW, I don't know of any simple and foolproof way to match up a live
client object in server side AS with the client information available in
the logs or admin api. Some people have requested that the internal
client id FCS uses be available as a property of the client object. I
think that's a great idea but don't think it is available in FMS 2.
There might be something new in the FMS 2 admin API or access.dll that
might help but I haven't come across it.
I also think that when a client starts playing or publishing data of any
kind you should be able to get an event in server-side AS (if you want
to) and even prohibit the request if you want to. However, it might be a
resource hog.
At any rate, I recommend you file a request for this as exposing the
internal id in the client object makes so much sense and "seems" like
such a simple thing.
http://www.macromedia.com/cfusion/m...m?name=wishform
Yours truly,
-Brian
lti-1a8g-LMbKfuCQv7pBDgjK7y7TUQ@public.gmane.org wrote:
> Hi,
>
> I'm trying to use efficiently the different convenient methods
> provided on the server side : getUserStats, getLiveStreamStats, and so
> on.
> The idea is to be able, whenenever a client disconnect or stops
> reading a live stream, to be able to know for how long he played the
> live stream.
>
> getLiveStreamStats ( proto: getLiveStreamStats(|/app_instance/|,
> |/stream_name/|) ) returns an object with two properties :
> -----------------quote-----------------------------------------------
> + publisher, Object; publisher statistics. The object has the
> following properties:
> * |name|: String; the name of the published live stream.
> * |time|: Date object; time that the stream was published.
> This property is a duplicate of |publish_time| and exists for
> backwards compatibility.
> * |type|: String; the type of stream for the publisher. The
> value is |"publishing"|.
> * |client|: Number; the client ID of the publisher.
> * |stream_id|: Number; the stream ID of the publisher.
> * |publish_time|: Date object; time that the stream was
> published.
> * |client_type|: String; the string type of the publishing
> client.
> * |publish_time|: Date object; time that the stream was
> published.
> + subscribers, Array of subscriber statistics. The array contains a
> |subscriber| property that is an object containing the following
> properties:
> * |client|: Number; user ID.|
> * subscribe_time|: Date object; the time that the user subscribed
> to the stream.
> -----------------quote-----------------------------------------------
>
> Here's the problem : how to link between a server side Client object,
> with all the interesting properties (agent, ip, referrer, etc...) and
> its Client ID ?
> Of course, if in "Programming FCS", and on many tutorials, there is
> info on "how to generate a unique client ID", may'be the answer is
> just : there isn't, but damn! it's so stupid. And it looks like it has
> not been *fixed* in FMS 2.
>
> When I see what Speedera has achieved, I wonder if they :
> a) paid extra bucks to get a decent documentation
> b) paid extra bucks to get Macromedia to build a specific version of FCS
> c) reverse engineered FCS and added the functionnalities themselves.
>
> PS: <rant time> Considering my past monthes' recurrent problems on
> Speedera network, a) & c) are highly improbable. Or the people who
> build the Speedera solution died in a plane crash. Or get fired
> monthes ago.
> I'm highly supportive to the ahem ... two ? people left which looks
> like they know something about the infrastructure of their
> services.</rant time>
>
>
>
>
>
> =-----------------------------------------------------------
> 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
--
________________________________________
______________________________
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
| |
| Ritesh Jariwala 2005-12-15, 2:45 am |
| I think, you can always store client as shared object on the server. I think
you can even get the stats about live stream.
So when ever client disconnect from the server you have to just update all
those info regarding client in server side shared object or into database
regarding that client.
I am agree with the brian that FMS 2 should have some kind of log mechanism
system so it can store all action perform by clients and stored on server
side.
With Regards,
Ritesh Jariwala (Actkid)
Freelance Developer
www.actkid.com
Company: www.synonymic.com
-----Original Message-----
From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of
lti-1a8g-LMbKfuCQv7pBDgjK7y7TUQ@public.gmane.org
Sent: Thursday, December 15, 2005 6:54 AM
To: FlashComm Mailing List
Subject: [FlashComm] How to link between internal IDs and SS Client /
Netstream objects ?
Hi,
I'm trying to use efficiently the different convenient methods provided
on the server side : getUserStats, getLiveStreamStats, and so on.
The idea is to be able, whenenever a client disconnect or stops reading
a live stream, to be able to know for how long he played the live stream.
getLiveStreamStats ( proto: getLiveStreamStats(|/app_instance/|,
|/stream_name/|) ) returns an object with two properties :
-----------------quote-----------------------------------------------
+ publisher, Object; publisher statistics. The object has the
following properties:
* |name|: String; the name of the published live stream.
* |time|: Date object; time that the stream was published.
This property is a duplicate of |publish_time| and exists for backwards
compatibility.
* |type|: String; the type of stream for the publisher. The
value is |"publishing"|.
* |client|: Number; the client ID of the publisher.
* |stream_id|: Number; the stream ID of the publisher.
* |publish_time|: Date object; time that the stream was
published.
* |client_type|: String; the string type of the publishing
client.
* |publish_time|: Date object; time that the stream was
published.
+ subscribers, Array of subscriber statistics. The array contains a
|subscriber| property that is an object containing the following properties:
* |client|: Number; user ID.|
* subscribe_time|: Date object; the time that the user subscribed
to the stream.
-----------------quote-----------------------------------------------
Here's the problem : how to link between a server side Client object,
with all the interesting properties (agent, ip, referrer, etc...) and
its Client ID ?
Of course, if in "Programming FCS", and on many tutorials, there is info
on "how to generate a unique client ID", may'be the answer is just :
there isn't, but damn! it's so stupid. And it looks like it has not been
*fixed* in FMS 2.
When I see what Speedera has achieved, I wonder if they :
a) paid extra bucks to get a decent documentation
b) paid extra bucks to get Macromedia to build a specific version of FCS
c) reverse engineered FCS and added the functionnalities themselves.
PS: <rant time> Considering my past monthes' recurrent problems on
Speedera network, a) & c) are highly improbable. Or the people who
build the Speedera solution died in a plane crash. Or get fired monthes ago.
I'm highly supportive to the ahem ... two ? people left which looks like
they know something about the infrastructure of their services.</rant time>
=-----------------------------------------------------------
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
=-----------------------------------------------------------
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
| |
| lti-1a8g-LMbKfuCQv7pBDgjK7y7TUQ@public.gmane.o 2005-12-15, 2:45 am |
| Hello Brian,
Thanks for your answer.
Actually there is a way to retrieve the internal client id FCS uses on
the client side : on "some" (I've seen it with NetStream.Play.Start on a
live stream, and it's not here with NetStream.Buffer.X) NetStream
events, the information object has a non-void "clientid" property whose
value matches the server's !
In such a situation, you can easily send back to the server the clientid
value with a NetConnection.call or else
The trick is that :
1) you rely upon the client to confirm its "server-side identity" : not
a great design and may'be a source of problems
2) if the client is not in the mood for streaming anything over the
established connection, you could wait for years before being able to
write your "correct" log lines
There might be a way to get this property in a Stream/NetStream event
server-side (I do think it's the way it's done at Speedera's as they are
basically performing live streams replication between node and edge
servers ...)
Regards,
lti-1a8
Brian Lesser wrote:
> FWIW, I don't know of any simple and foolproof way to match up a live
> client object in server side AS with the client information available
> in the logs or admin api. Some people have requested that the internal
> client id FCS uses be available as a property of the client object. I
> think that's a great idea but don't think it is available in FMS 2.
> There might be something new in the FMS 2 admin API or access.dll that
> might help but I haven't come across it.
>
> I also think that when a client starts playing or publishing data of
> any kind you should be able to get an event in server-side AS (if you
> want to) and even prohibit the request if you want to. However, it
> might be a resource hog.
>
> At any rate, I recommend you file a request for this as exposing the
> internal id in the client object makes so much sense and "seems" like
> such a simple thing.
>
> http://www.macromedia.com/cfusion/m...m?name=wishform
>
> Yours truly,
> -Brian
>
> lti-1a8g-LMbKfuCQv7pBDgjK7y7TUQ@public.gmane.org wrote:
>
>
>
>
>
=-----------------------------------------------------------
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
| |
| lti-1a8g-LMbKfuCQv7pBDgjK7y7TUQ@public.gmane.o 2005-12-15, 2:45 am |
| Well actually, I did consider using the same recipes as the AccessLog
and BandwidthLog mechanism applied to an application-level log mechanism
(which exists : if you activate it - look for the RecorpAppLog(s) entry
in the config files - you can record whatever you "trace" on the server
side).
But the point is that some very useful functions request a "client_id"
or "user_id" (*) parameter which uniquely identify a client connected to
FCS, but this "client_id" is not exposed in the "Client" actionscript
object (whereas a client's ip, refererrer, user agent, etc ... are).
So you have to perform tricky operations to be able to get this
"client_id", at least. I'm not even sure if there's a foolproof way to
do it server-side.
Every way I thought of used the client somehow (forcing the client to
subscribe to a particular stream with a random part in the stream name,
accessing this live streams stats and getting the subscribers', etc..).
Regards,
lti-1a8g
(*) Have a look in the "communication app inspector", in the "streams
panel", which display the list of active streams and their subscribers'
internal "client_id"s
Ritesh Jariwala wrote:
>I think, you can always store client as shared object on the server. I think
>you can even get the stats about live stream.
>
>So when ever client disconnect from the server you have to just update all
>those info regarding client in server side shared object or into database
>regarding that client.
>
>I am agree with the brian that FMS 2 should have some kind of log mechanism
>system so it can store all action perform by clients and stored on server
>side.
>
>With Regards,
>
>Ritesh Jariwala (Actkid)
>Freelance Developer
>www.actkid.com
>Company: www.synonymic.com
>
>
>-----Original Message-----
>From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
>[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of
>lti-1a8g-LMbKfuCQv7pBDgjK7y7TUQ@public.gmane.org
>Sent: Thursday, December 15, 2005 6:54 AM
>To: FlashComm Mailing List
>Subject: [FlashComm] How to link between internal IDs and SS Client /
>Netstream objects ?
>
>Hi,
>
>I'm trying to use efficiently the different convenient methods provided
>on the server side : getUserStats, getLiveStreamStats, and so on.
>The idea is to be able, whenenever a client disconnect or stops reading
>a live stream, to be able to know for how long he played the live stream.
>
>getLiveStreamStats ( proto: getLiveStreamStats(|/app_instance/|,
>|/stream_name/|) ) returns an object with two properties :
>-----------------quote-----------------------------------------------
> + publisher, Object; publisher statistics. The object has the
>following properties:
> * |name|: String; the name of the published live stream.
> * |time|: Date object; time that the stream was published.
>This property is a duplicate of |publish_time| and exists for backwards
>compatibility.
> * |type|: String; the type of stream for the publisher. The
>value is |"publishing"|.
> * |client|: Number; the client ID of the publisher.
> * |stream_id|: Number; the stream ID of the publisher.
> * |publish_time|: Date object; time that the stream was
>published.
> * |client_type|: String; the string type of the publishing
>client.
> * |publish_time|: Date object; time that the stream was
>published.
> + subscribers, Array of subscriber statistics. The array contains a
>|subscriber| property that is an object containing the following properties:
> * |client|: Number; user ID.|
> * subscribe_time|: Date object; the time that the user subscribed
>to the stream.
>-----------------quote-----------------------------------------------
>
>Here's the problem : how to link between a server side Client object,
>with all the interesting properties (agent, ip, referrer, etc...) and
>its Client ID ?
>Of course, if in "Programming FCS", and on many tutorials, there is info
>on "how to generate a unique client ID", may'be the answer is just :
>there isn't, but damn! it's so stupid. And it looks like it has not been
>*fixed* in FMS 2.
>
>When I see what Speedera has achieved, I wonder if they :
>a) paid extra bucks to get a decent documentation
>b) paid extra bucks to get Macromedia to build a specific version of FCS
>c) reverse engineered FCS and added the functionnalities themselves.
>
>PS: <rant time> Considering my past monthes' recurrent problems on
>Speedera network, a) & c) are highly improbable. Or the people who
>build the Speedera solution died in a plane crash. Or get fired monthes ago.
>I'm highly supportive to the ahem ... two ? people left which looks like
>they know something about the infrastructure of their services.</rant time>
>
>
>
>
>
>=-----------------------------------------------------------
>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
>
>
>
>=-----------------------------------------------------------
>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
>
>
=-----------------------------------------------------------
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
|
|
|
|
|