Recently in Snyggast Chatten Category
The web chat I am running has support for four public webcams, visible to everyone. The idea is that a user can occupy one slot for a maximum of five minutes. Unfortunately, as with any public system, there will always be those who misbehave. Therefore, when making the new webcam system, one of the new key features will be improved ban handling as well as user reporting abilities. This articles covers the latter.
What we came up with is a powerful, yet simple to use report system. This includes one-click reporting, data gathering and automatic snapshots of the webcam in question. After all, we want to see what the user saw when he pressed the report button.
In short, when a user sees any suspicious activity, he or she can simply click the report button. A snapshot is then generated and information such as nicknames and IPs of both reporter and the user being reported is collected.
Server setup
I am using two servers, one for the chat itself and one for the Flash Media Server. Flash Media Server, or FMS, is the software which makes it possible for us to broadcast webcams and streaming video in Flash. Both servers are running a web server with PHP installed and thanks to AmfPHP we can call PHP scripts on the chat server straight from FMS.
Requirements
Everything must be made server-side, for security reasons the client itself cannot generate the snapshot. The reports will be stored in the mySQL database on the main server, Chat.
Known problems
Flash Media Server cannot generate snapshots, only record video into Flash Live Video (.flv). This means we have to run FFMPEG (a free media encoder) from shell to convert FLV to Snapshots (.jpg).
Key players, or the system in short
The system consists of three major players. On the cam server we've got Flash Media Server and the PHP script generateJPG.php. generateJPG.phps sole mission is to do on-the-fly conversions between the Flash Live Video (.flv) and JPEG. On the chat server we've got the PHP function continueReport() which stores everything in the database. continueReport() is reachable from FMS thanks to AmfPHP.
The report life cycle simplified
When a user presses "Report" a function is executed in our Flash Media Server application. FMS records a one second long video clip which it stores locally for generateJPG.php. It then gathers the needed information (IP numbers, nicknames etc.) which it passes onto continueReport() on the chat server. continueReport() then downloads the snapshot in question using generateJPG.php and stores the JPG on disk, and the rest in our mySQL database.
In reality
However, the simplified version does not show connections and request replies between the scripts. In reality, this is what happens:
1. The user clicks on the report button, thus making a call to FMS.
2. FMS starts recording and stops, by timer, after 1 second.
3. FMS (using AmfPHP) sends a request to continueReport() and waits for a "OK" reply.
1. continueReport() receives the request and
makes a call to PHP on server Cam for a snapshot.
1. Cam's PHP run the shell program FFMPEG, thus
generating a .jpg snapshot which is echos back to Chat.
2. continueReport(), still running, now has the image as a
string and starts by saving the report data (IPs etc) in the
mySQL database. After that, it then stores the image on the disk.
3. continueReport(), which now is done with its operations,
send the "OK" reply to FMS.
4. FMS removes the temporary stream saved in step 2
To be continued...
And there you have it, connections and request replies included. I haven't had the time to explain and comment the source code yet, but when I do I will add another articles with at least the FMS source and a FFMPEG guide. If you are really interested, contact me and I'll hook you up.
What we came up with is a powerful, yet simple to use report system. This includes one-click reporting, data gathering and automatic snapshots of the webcam in question. After all, we want to see what the user saw when he pressed the report button.
In short, when a user sees any suspicious activity, he or she can simply click the report button. A snapshot is then generated and information such as nicknames and IPs of both reporter and the user being reported is collected.
Server setup
I am using two servers, one for the chat itself and one for the Flash Media Server. Flash Media Server, or FMS, is the software which makes it possible for us to broadcast webcams and streaming video in Flash. Both servers are running a web server with PHP installed and thanks to AmfPHP we can call PHP scripts on the chat server straight from FMS.
Requirements
Everything must be made server-side, for security reasons the client itself cannot generate the snapshot. The reports will be stored in the mySQL database on the main server, Chat.
Known problems
Flash Media Server cannot generate snapshots, only record video into Flash Live Video (.flv). This means we have to run FFMPEG (a free media encoder) from shell to convert FLV to Snapshots (.jpg).
Key players, or the system in short
The system consists of three major players. On the cam server we've got Flash Media Server and the PHP script generateJPG.php. generateJPG.phps sole mission is to do on-the-fly conversions between the Flash Live Video (.flv) and JPEG. On the chat server we've got the PHP function continueReport() which stores everything in the database. continueReport() is reachable from FMS thanks to AmfPHP.
The report life cycle simplified
When a user presses "Report" a function is executed in our Flash Media Server application. FMS records a one second long video clip which it stores locally for generateJPG.php. It then gathers the needed information (IP numbers, nicknames etc.) which it passes onto continueReport() on the chat server. continueReport() then downloads the snapshot in question using generateJPG.php and stores the JPG on disk, and the rest in our mySQL database.
In reality
However, the simplified version does not show connections and request replies between the scripts. In reality, this is what happens:
1. The user clicks on the report button, thus making a call to FMS.
2. FMS starts recording and stops, by timer, after 1 second.
3. FMS (using AmfPHP) sends a request to continueReport() and waits for a "OK" reply.
1. continueReport() receives the request and
makes a call to PHP on server Cam for a snapshot.
1. Cam's PHP run the shell program FFMPEG, thus
generating a .jpg snapshot which is echos back to Chat.
2. continueReport(), still running, now has the image as a
string and starts by saving the report data (IPs etc) in the
mySQL database. After that, it then stores the image on the disk.
3. continueReport(), which now is done with its operations,
send the "OK" reply to FMS.
4. FMS removes the temporary stream saved in step 2
To be continued...
And there you have it, connections and request replies included. I haven't had the time to explain and comment the source code yet, but when I do I will add another articles with at least the FMS source and a FFMPEG guide. If you are really interested, contact me and I'll hook you up.
Recently I've been working on a new version of my webcam software for Snyggast Chatten. Basically it allows our users to broadcast their webcams and view others. Here is a quick GUI preview:
The new system is re-written from the ground up. The GUI is better, users can report rule violations, we can maintain bans easier. Everything is simply better. More information will follow..
The new system is re-written from the ground up. The GUI is better, users can report rule violations, we can maintain bans easier. Everything is simply better. More information will follow..
Introduction
There are many good sites for website statistics. Tools such as Google Analytics are invaluable for any webmaster. But how do you measure the success of a chat? a IRC system? While total number of users per day is interesting, the real value is in the current number of users combined with other factors.
Helios, our new statistical software I've been working, is an internal tool for us on Snyggast Chatten. It collects data every five minutes, pretty much like mrtg. MRTG stands for Multi Router Traffic Grapher, and outputs images like this:
Where a webmaster can easily overlook the network usage of a particular server. The idea is to output similar graphs but include data such as current numbers of users, ram usage, etc.
Collected data
Currently we are collecting the following data every five minutes:
Relations, the real power
The real power of Helios is relations. In a 24 hour graph we can not only see where our tops are, but also the relationship between numbers of users and, for example, free ram. This provides us with valuable information about how the server feels but also how much a particular optimization gave us.
The actual charts
I've built the system around the open source grapher Open Flash Charts. It's a flash grapher, and it's open source. Since we will be measuring numbers of users (0-600) and it's relation with ram usage (0-2500 MB free) we need double Y-axes. The problem is that not many (if any) grapher actually supports this by default. But since Open Flash Charts are open source I could implement it myself. Turns out that many other users have been asking for this feature for a long time and my double y-axes code will be integrated in the next release of the software. It's always good to be able to contribute to projects..
Sample Chart
This is how the system currently looks:
At a first glance it's quite blurry and might be hard to see the relations. This is because the large number of data we actually need to see. The main line (with the dots) are numbers of chat users, the smaller line with dots are numbers of webcam users and the other 2 lines are how much ram we have left.
Why the name Helios?
In greek mythology, Helios is the sun god and referred to as the "the all-seeing". A fitting name for a system which idea is to monitor and see pretty much everything.
There are many good sites for website statistics. Tools such as Google Analytics are invaluable for any webmaster. But how do you measure the success of a chat? a IRC system? While total number of users per day is interesting, the real value is in the current number of users combined with other factors.
Helios, our new statistical software I've been working, is an internal tool for us on Snyggast Chatten. It collects data every five minutes, pretty much like mrtg. MRTG stands for Multi Router Traffic Grapher, and outputs images like this:
Where a webmaster can easily overlook the network usage of a particular server. The idea is to output similar graphs but include data such as current numbers of users, ram usage, etc. Collected data
Currently we are collecting the following data every five minutes:
- IRC data (Numbers of users, users in both public channels, active admins, webclient users)
- System data (Ram usage, HDD usage, CPU usage)
- Webcam data (Numbers of webcam users
Relations, the real power
The real power of Helios is relations. In a 24 hour graph we can not only see where our tops are, but also the relationship between numbers of users and, for example, free ram. This provides us with valuable information about how the server feels but also how much a particular optimization gave us.
The actual charts
I've built the system around the open source grapher Open Flash Charts. It's a flash grapher, and it's open source. Since we will be measuring numbers of users (0-600) and it's relation with ram usage (0-2500 MB free) we need double Y-axes. The problem is that not many (if any) grapher actually supports this by default. But since Open Flash Charts are open source I could implement it myself. Turns out that many other users have been asking for this feature for a long time and my double y-axes code will be integrated in the next release of the software. It's always good to be able to contribute to projects..
Sample Chart
This is how the system currently looks:
At a first glance it's quite blurry and might be hard to see the relations. This is because the large number of data we actually need to see. The main line (with the dots) are numbers of chat users, the smaller line with dots are numbers of webcam users and the other 2 lines are how much ram we have left.
Why the name Helios?
In greek mythology, Helios is the sun god and referred to as the "the all-seeing". A fitting name for a system which idea is to monitor and see pretty much everything.
Recently I implemented support for double, stand-alone y-axis in Open Flash Charts. Turns out that John Glazebrook (main coder) has gotten "LOTS of requests for 2 Y axis" and my contribution will be included in the next release of Open Flash Charts. That way all users can benefit from my modifications..
Technical details (to other Open Flash Charts users)
If you want to try out double y-axis before the next release, download my open-flash-chart.swf and add this to your data file:
&y2_axis_colour=#164166& // Same as regular documentation
&y2_label_style=10,0x164166& // Same as regular documentation
&show_y2=true& // Do we use double axels?
&y2_lines=1& // Which of the lines should be drawn based on the y2-axel? (1,2,3 etc)
&y2_left=70& // Left margin (how far left should we push the regular content)
&y2_min=0& // Same as regular documentation
&y2_max=2400& // Same as regular documentation
&y2_legend=Free Ram (mb),12,0x164166& // Same as regular documentation
Good luck! If you got any questions, simply contact me
Technical details (to other Open Flash Charts users)
If you want to try out double y-axis before the next release, download my open-flash-chart.swf and add this to your data file:
&y2_axis_colour=#164166& // Same as regular documentation
&y2_label_style=10,0x164166& // Same as regular documentation
&show_y2=true& // Do we use double axels?
&y2_lines=1& // Which of the lines should be drawn based on the y2-axel? (1,2,3 etc)
&y2_left=70& // Left margin (how far left should we push the regular content)
&y2_min=0& // Same as regular documentation
&y2_max=2400& // Same as regular documentation
&y2_legend=Free Ram (mb),12,0x164166& // Same as regular documentation
Good luck! If you got any questions, simply contact me
