| Pritham Shetty 2005-12-15, 5:45 pm |
| Exposing the client id is simple. We had some concerns in terms of
supporting it future versions and also what the end user expectations
would be on the id. One of the things in the current id generation
scheme, an id can be reused immediately after a client has disconnected.
If script is using this for unique mapping and it is still holding onto
disconnected clients you can run into problems.
One other problem is in FMS 2 edge-origin deployment, client id's on the
origin can be different from the id's on the edge. Creating a unique
id's across multiple servers is a challenge.
Let me ask a couple of questions on what you want this id to be:
1) unique across all application instances on a given server
2) id's are never reused.
3) unique only for the application instance.
Would it be better if we provided a mechanism where you can set a FMS
defined property before you call accept or reject connection and we log
this as one of the fields in access log and also return it as part of
admin commands?
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: Thursday, December 15, 2005 7:09 AM
To: FlashComm Mailing List
Subject: Re: [FlashComm] How to link between internal IDs and SS
Client/Netstream objects ?
Thanks Pritham,
That's helpful and good to know. But I don't think it is simple. I=20
really think that, unless there are technical hurdles, that you should=20
expose the internal client id as a property of the client object in a=20
future updater or later relase. It should be trivially simple for an=20
application developer to match client object to internal id as
necessary.
It's too bad optionally catching publishing events could do so much=20
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=3Dxyz
>
>Similarly you can use NetStream.play( "foo?user=3Dxyz" );
>
>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=20
>
>function Result()
>{
> this.onResult =3D 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=20
>client object in server side AS with the client information available
in
>
>the logs or admin api. Some people have requested that the internal=20
>client id FCS uses be available as a property of the client object. I=20
>think that's a great idea but don't think it is available in FMS 2.=20
>There might be something new in the FMS 2 admin API or access.dll that=20
>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=20
>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=20
>internal id in the client object makes so much sense and "seems" like=20
>such a simple thing.
>
>http://www.macromedia.com/cfusion/m...name=3Dwishform
>
>Yours truly,
>-Brian
>
>lti-1a8g-LMbKfuCQv7pBDgjK7y7TUQ@public.gmane.org wrote:
>
> =20
>
>
> =20
>
>
> =20
>
>
> =20
>
>
> =20
>
>
> =20
>
>FCS
> =20
>
>
>
>
> =20
>
--=20
________________________________________
______________________________
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
________________________________________
______________________________
=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
|