| Brian Lesser 2005-12-15, 5:45 pm |
| Thanks Pritham,
That's helpful and good to know. But I don't think it is simple. I
really think that, unless there are technical hurdles, that you should
expose the internal client id as a property of the client object in a
future updater or later relase. It should be trivially simple for an
application developer to match client object to internal id as necessary.
It's too bad optionally catching publishing events could do so much
damage in an origin setup. Maybe one day we can push filtering code that
can manage those events out to the edge.
Thanks again,
-Brian
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" );
>
>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.
>
>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() );
>
>
>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.
>
>
>
>
>
>
>
>-----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
>
>
>
>
>
>
>
--
________________________________________
______________________________
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
|