monline

Btw. you could have used the output of netstat too. Using lsof here is kind of shooting a sparrow with a cannon.

You're right, at least partly. FMS might not just listen on the 1935 TCP port. Eg. in my setup it listens on 443 and 80 too. There's an RTMPT protocol that stands for "RTMP over HTTP tunnel". If your player SWF implements this, it is possible that it first tries to connect to port 1935 via RTMP and if it does not succeed within a certain timeperiod, it tries port 80 via RTMPT. An even better solution is (in respect of client wait time) if the player initiates a connection to port 1935 and if it did not succeed in eg. 2 seconds, it automatically initiates a connection to 80 port via RTMPT. And the player uses the connection that first successfully connects to the server and drops/closes the other one. This is what we use in our player.

On the other hand you're right: there's a significant discrepancy between what I see from netstat output and what I get from the plugin (which gets the stats from the FMS Admin server's getAppStats() call.

Initially I thought I could explain this. The FMS Admin server shows a number with _active_ stream connections, while netstat shows any kind of a TCP connection. The latter can be even a connection that is not yet fully estabilished or that has been already ended and is waiting for being cleaned up. Take a look at the manpage of netstat. You'll find in the "State" section the list of various states of a TCP connection:

• ESTABLISHED: The socket has an established connection.
• SYN_SENT: The socket is actively attempting to establish a connection.
• SYN_RECV: A connection request has been received from the network.
• FIN_WAIT1: The socket is closed, and the connection is shutting down.
• FIN_WAIT2: Connection is closed, and the socket is waiting for a shutdown from the remote end.
• TIME_WAIT: The socket is waiting after close to handle packets still in the network.
• CLOSE: The socket is not being used.
• CLOSE_WAIT: The remote end has shut down, waiting for the socket to close.
• LAST_ACK: The remote end has shut down, and the socket is closed. Waiting for acknowledgement.
• LISTEN: The socket is listening for incoming connections. Such sockets are not included in the output unless you specify the --listening (-l) or --all (-a) option.
• CLOSING: Both sockets are shut down but we still don’t have all our datasent.
• UNKNOWN: The state of the socket is unknown.

The FMS Admin server could report only connections that are in ESTABLISHED state and that are "active", meaning that the connection had traffic in the last period of the FMS Admin Server statistics updater module. But unfortuantely this is not true. I just saw the FMS Admin server returning the number 60 for the "vod" application and netstat reports only 39 connections (btw. all of them are ESTABLISHED, no connections between the FMS server and clients were in any other state).

It seems FMS Admin server sucks in every way. I'll modify the basic fms Munin plugin (that does not split connections by applications) to work based on netstat. It seems there's no real stat in FMS Admin Server's output that could give us the _real_ number of actual streams. It'd be nice if Adobe published some "real" documentation on how these stats in FMS Admin Server work. The description in the "FMS Administration API Reference" is crap and explains nothing. Or at least it does not give a plausible explanation on how to reproduce the numbers that FMS Admin Server reports. And certainly those numbers are not what FMS admins are interested in.