几个使用过程几个不方便的地方

passerby

1、策略计划只能删除不能修改，不是很方便~~~

2、策略计划很定义很麻烦，比如我要早上跟下午上班时间一种，中午晚上休息时间一种，半夜一种，这样就很恐怖了，每天都要定义五次~~
    是不是考虑，将星期几弄成用复选框选的，然后时间弄成定义时间段的~~特别是星期几一定要弄成复选框的，或者定义成三种类型（每天、周一至周五、周未）

3、通道只能修改带宽，不是很方便~~~

4、用户名最好可以修改~~~

5、是不是考虑增加实时流量监控，那个流量概况好象很久才更新一次，不能完全反映实时情况

6、内网监控的功能好象不实用，不能自定义按上传或下载排序，好象我看不出是按什么数据排序的
     如果可能，还可以增加按不同应用类型排序，比如按P2P下行流量排序

7、能不能增加总流量控制功能，比如说，如果单台机某个时间段下载超过一G，那就自己封锁多久


哈哈，目前就想到这么多~~~~~开发新版本时可以考虑一下~~~~

passerby

对了，是不是考虑开放一定的二次开发接口，这样可以让网友帮忙开发插件

panabit

原帖由 passerby 于 2007-12-23 15:55 发表
对了，是不是考虑开放一定的二次开发接口，这样可以让网友帮忙开发插件

Good idea?
觉得开放什么样的接口比较好?

Lucifer

能添加的功能也只能是数据的统计显示等功能。除非panabit和其他网络应用的协调性得到解决。

但是我们之前讨论过这种产品是很无意义的。

倒是我们之前说的C/S是不是该实现了。呵呵

passerby

数据统计显示这个不错~~~

另外象我说的当流量到一定程度后自动封锁,类似这种的只有要接口也可以自己开发啊~~开放数据库内容,然后提供个阻止的函数~~

或者把所有基础功能都做成独立的函数~~~然后象我在贴里说那的些不便之处,都可以自己解决了


总结就是两点,哈,1\功能函数,2\数据库内容读写

passerby

这样你们就可以把精力放在协议分析,还有你们说的那个panabitos之上了~~

panabit

我们可以提供接口，但是在这之前，大家需要充分讨论一下：
（1）提供什么样的接口
（2）如何提供

Lucifer

我觉得这个很值得商榷。

我只是表示我的看法，我并不对开放接口反对。

我认为开放接口后被攻击的可能性大大提高，panabit这种设备非常关键因为运行在非常核心的位置，如果出现问题会造成内外网完全瘫痪。这么做是否得不偿失？

我感觉仅仅提供数据传出的接口比较好，图形化功能利用本地程序进行处理。还有panabit，我的意见我觉得你应该在考虑下。

本地的客户端到底是用C++还是java实现。因为在我们这个圈子里java库的问题因该不能称之为一个问题。




至于基于客户端的远程控制……这种东西的存在本身就是个威胁，大家不认为吗？

passerby

panabit是桥接的，只分析通过的包，并不接收，应该不存在被攻击的可能～～（管理口除外）

而且一般是接在内网吧，总不能让panabit接在路由器外面～～～

开发接口只提供本机运行，用C/S模式更不安全～～感觉b/s模式安全点～～

数据显示的话，m0n0用了adobe 的svgview，我没研究过，不过应该是服务器传数据过来，图形在本地用这个控件生成，很不错，不用刷新网页，而图表实时更新

Lucifer

哦哦。那我和楼上的意见基本一致了。利用控件生成图形这是一个好的选择毕竟在服务器端很受限制。

C/S是一种方式。集群化管理肯定还是需要这样的。实现方式可以在想象。