Hi Thierry,

Thanks to you and others, for providing the "update to latest or beta"
solution, I'll give it at try!

   Basically you have got me convinced that SVG is probably a decent
choice. Still I can't resist commenting on some of what you say, even
if I won't go as far as to suggest that the work already done be
dropped in favour of what may just be my pesonal preference:

- I wasn't aware that Flash required a license to use? (Other than
purchasing the development software, that is.) I can see how this
would be a problem. Anyway, I only suggested Flash because I wasn't
aware that SVG was a W3C standard. Knowing this, I think I too prefer
SVG, even if I would still be happier with the PNG solution. The main
reason for this being that it doesn't require anything of the browser,
plugins or otherwise (with the possible execption of JavaScript, which
I think is already a requirement for the m0n0wall webGUI?)

- While I can't argue about the added network load with the PNG based
solution (even if I don't see this as a big problem, assuming most
people will be on the LAN side when viewing the graph, also this can
be reduced to a bare minimum, even removed entirely, as explained
below), I should think it possible to avoid the problem with reloading
(and the visual artifact this entails), by letting a few lines of
JavaScript load the image in the background and then swap it with the
image shown on the page, a technique used in many a "MouseOver"
scripts, as seen on numerous webpages on the internet. This would also
allow an arbitrary update frequency as opposed to auto-refreshing the
whole page, while removing the need for transfering anything but the
image. Finally a PNG, using a limited number of colours with a single
background color dominating, should be quite small (a few KB at the
most, probably less if done correctly).

- I don't understand the bit about the PHP process having to restart
every time, but then again I'm no expert on this? Assuming this has to
do with the page-reloading issue, it is easily avoided as described above.

- In case your are very concerned about CPU usage (personally I have
plenty to spare, and wouldn't consider running m0n0wall on anything
slower than a 4801 anyway), you could resolve this, provided you were
willing to code the graph-imager yourself (as opposed to using
something already freely available) It might even be possible to do
with a sufficiently good existing program. Thus it should be possible
to reuse more than 99% of the image from frame to frame, computing
only a few new pixels each time (the single vertical line that is
added to one side of the graph for each new frame). I don't think this
would be detectable on the CPU usage at all, even on a 4501, and not
even with several frames being produced every second, since the
calculations involved would be something like what it takes for
m0n0wall to consider a single firewall rule for a single packet. In
fact these calculations could probably be done in PHP without too much
overhead, removing the need for any binary code to be added to the image.

- Similar, if you are concerned about network usage, you could build
the graph from a large number of thin vertical "strips" (possibly just
a single pixel wide), and have a simple JavaScript scroll these
around, dropping the oldest and adding the newly recieved strip. Then
only a single strip would have to be sent for each frame, making the
bandwidth usage per frame drop to something like a few hundred bytes
per frame. This would amount to less than 1 KB per second, even with a
refresh rate of 5-10Hz, which should be more than enough. This would
also lower the computations done by m0n0wall to next to nothing.

- Come to think of it, the above could be implemented entirely on the
client side, using either JavaScript to mainpulate a BMP image or a
small Java applet (which I consider a little better than a plugin,
even if I have some of the same objections). Either way, the network
load and the PHP needed would be much, if not entirely, the same as
for the SVG applet (that is, only the actual data would need to be
transfered). If I should, by some miracle, get the time, I will
certainly look into this myself. Wouldn't we all agree that Java or
JavaScript is to be prefered over any other solution?

Regards,

Adam.

T. Lechat wrote:
> Hi,
> 
> For the problem you describe, Konstantin got you a probably correct answer.
> 
>>Just go to Adobe site and install latest SVG viewer
> 
> Try with SVG 3.0 or 3.01 and if it doesn't solve your problem, try the beta
> 6
> 
> About your others questions/suggestions :
> I can get you some pieces of answer :
> 
>>I was a bit surprised to see this particular (SVG) solution used for
>>the traffic grapher. Perhaps someone would care to elaborate on the
>>reasons behind this choice?
> 
> 
> SVG is probably, I hope, the next Internet Standard about vectoriel graphic.
> This is a standard on W3C, and as far as I know, most of browser support it.
> Note too, that adobe svg plugin 1.0 is widely installed since it was
> distributed quietly in the adobe pdf plugin 5.
> SVG is particulary well adapted to be generated by php like script.
> SVG does not requires any commercial licence to be generated (not like flash
> or shockwave) Because you need no generator to play with it. It's like html,
> human readable and writeable (-; without any soft.
> Not only adobe have made svg plugin, there is also a corel plugin and two
> other less-knew company have their own.
> 
> 
>>Personally though, I would consider an approach where a dynamically
>>produced image (PNG or GIF) was used to show the graph(s), so as to
>>avoid the need for a plugin and thus keeping the webGUI as compatible
>>as possible.
> 
> It is another solution. But if you want the same realtime graph, it will be
> more ressource cruncher that you think, since you need to restart a php
> process every time. And it is less 'esthetic' since you need to reload and
> refresh the page where gif stand with all blank time you will probably got..
> And I forget to include network traffic to reload the graph (-;
> 
> 
>>But I get the impression that this new graph page
>>wasn't intended for doing long-term statistical analysis, and so
>>wouldn't be expected to remain active for extended periods )
> 
> The SVG traffic grapher is really stable and do not consume a lot of
> ressource on m0n0wall. Since m0n0wall is just responsible to get new value
> of data at each refresh cycle. Calculation and drawing are made by the
> browser. And as you will see, there is no more ressource eated on browser
> side to do that. I personnaly use 'SVG traffic grapher like' for month,
> without restarted browser. So you can quietly used it for a long period.
> About doing long time analysis, it is better to use external tools like mrtg
> or rrd or any stuff especially designed to do that.
> 
> 
>>In case this approach is deemed unfeasible, I'd consider a solution
>>similar to the current one, but using Shockwave Flash instead. At
>>least this is a very common, and widely supported plugin. Some
>>browsers (notably IE) even come with built-in Flash support, removing
>>the need to install a plugin altogether.
> 
> 
> As I said Shockwave is a commercial solution, and that means that creator of
> shockwave must buy licence. I think it is not the way of m0n0wall. If you
> have a licence, just make the shockwave traffic grapher and proposed it to
> manuel (-;
> 
> 
>>There is also the issue of company policies regarding installation of
>>plugins to consider, which will probably be less of an issue with
>>Flash, and non-existent with the dynamic-PNG solution.
> 
> No trouble about svg adobe plugin : public and commercial licence are free
> of charge and it is distributed in the same way that flash.
> 
> 
>>Anyway, just my two cents. And don't get me wrong: No matter how it is
>>implemented, I'm a sucker for anything graphic and "blinkenlichten"
>>and am very happy to see this particular feature making it into the
>>beta (and hopefully the release at some point). Now, about that
>>suggestion for a 3D screensaver in the m0n0wall webGUI... :))
> 
> If you are happy, it's fine. I'm happy too to see this feature in this
> release. And sure lot of users will be too. (I hope }-; )
> 
> 
>>P.S. Please excuse my longwindedness, can't help it I'm afraid :(
> 
> Not too bad (-;
> 
> At end, I just will say that SVG Traffic Grapher is one of many solutions.
> Maybe not the best, maybe not the worst, just a good look and useable
> solution.
> 
> - Thierry       (who like SVG as you can see)
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
>