passerby 发表于 2007-12-23 15:51:56

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

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

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

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

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

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

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

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


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

passerby 发表于 2007-12-23 15:55:16

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

panabit 发表于 2007-12-23 19:18:34

原帖由 passerby 于 2007-12-23 15:55 发表 http://www.panabit.com/forum/images/common/back.gif
对了,是不是考虑开放一定的二次开发接口,这样可以让网友帮忙开发插件

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

Lucifer 发表于 2007-12-23 19:35:27

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

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

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

passerby 发表于 2007-12-23 21:13:01

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

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

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


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

passerby 发表于 2007-12-23 21:13:51

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

panabit 发表于 2007-12-23 21:46:34

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

Lucifer 发表于 2007-12-23 23:20:36

我觉得这个很值得商榷。

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

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

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

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




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

passerby 发表于 2007-12-24 00:50:28

panabit是桥接的,只分析通过的包,并不接收,应该不存在被攻击的可能~~(管理口除外)

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

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

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

Lucifer 发表于 2007-12-24 10:11:16

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

C/S是一种方式。集群化管理肯定还是需要这样的。实现方式可以在想象。
页: [1] 2 3
查看完整版本: 几个使用过程几个不方便的地方