| lti-1a8g-LMbKfuCQv7pBDgjK7y7TUQ@public.gmane.o 2005-12-15, 2:45 am |
| Pritham Shetty wrote:
>One of the things you can use to correlate client connection with access
>log is to add url encoded params to rtmp uri or your play string
>
>For example rtmp://<server>/app/inst?user=xyz
>
>Similarly you can use NetStream.play( "foo?user=xyz" );
>
>
Sure, but it's still building yet another "unique id" that doesn't help
in using the getXXXStreamsStats() or the getUserStats function ...
>You can log : connect, disconnect, play stop events and also configure
>logger to log specific fields, uri, uri-stem or uri-query, etc. Refer to
>documentation or logger.xml for list of all the fields and events you
>can log.
>
>
>
This sounds interesting ...
Is this part of the FCS 1.5r2 distribution or FMS2 specific ?
("logger.xml")
>One simple scheme you can use is to have a counter in your instance and
>return this to the client as part of connect response. Use this id as
>param in your play request.
>
>Here is an undocumented api that allows you to get the client id
>
>function Result()
>{
> this.onResult = function( id ){
> trace( "Client ID " + id );
> }
>}
>
>// returns the client id associated by the server for this client.
>nc.call("@getClientID", new Result() );
>
>
>
argh ! I noticed the "@getCliendID" when performing a 'strings | grep -i
clientid' on the FCS binaries but the "@" scared me 
>On notification to script on play publish events it is a scalability
>issue. In an edge-origin deployment scenario origin can become a
>bottleneck if it needs to coordinate all requests.
>
>
>Pritham.
>
>
>
Regards,
lti-1a8g
>-----Original Message-----
>From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
>[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of Brian
>Lesser
>Sent: Wednesday, December 14, 2005 7:28 PM
>To: FlashComm Mailing List
>Subject: Re: [FlashComm] How to link between internal IDs and SS Client
>/Netstream objects ?
>
>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:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>FCS
>
>
>
>
>
>
>
=-----------------------------------------------------------
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
|