#
ZSP project started.SourceView2.0 and SourceFlow1.0 will be
deployed there.
This project is my first project since I came to GZ,wishing it
success.
Fedora为什么不用mp3，而选择ogg？
Freedom: Make ogg, not mp3
Why is mp3 popular? Because it's better than everything else out there?
No. mp3 is popular because its creators licensed it broadly to spur its adoption. Then, once it was the de facto format, they started to enforce their patents aggressively and restrictively.
The free and open multimedia codecs such as the Ogg family of codecs are superior, and they are not patent-encumbered. Never have been, never will be. That's why we support free and open formats like Ogg Vorbis (lossy) and FLAC (lossless) for general audio and Ogg Theora for video.
For those people who insist upon using mp3, it's not difficult to figure out how to get these players. Still, we'd much rather change the world instead of going along with it.
http://fedoraproject.org/wiki/Overview
An operating system, a set of projects, and a mindset.
What is Fedora? Fedora is a Linux-based operating system that showcases the latest in free and open source software. Fedora is always free for anyone to use, modify, and distribute. It is built by people across the globe who work together as a community: the Fedora Project. The Fedora Project is open and anyone is welcome to join. The Fedora Project is out front for you, leading the advancement of free, open software and content.
The operating system is Fedora. It comes out twice a year. It's completely free, and we're committed to keeping it that way. It's the best combination of robust and latest software that exists in the free software world.
The mindset is doing the right thing. To us, that means providing free and open software and content, at no cost, freely usable, modifiable, redistributable, and unencumbered by software patents.
觉得Fedora做得挺好，特别是对我们这样的程序员。
集成了MySQL,Tomcat,JDK,Eclipse,C的编译器以及C的库文件，简直是天然的开发环境。
今天用c连接mysql,调试成功。
编译包含mysql的c程序的命令如下：
[root@localhost ~]# gcc -o /forc/testmy /forc/testmy.c -lz /usr/lib/mysql/libmysqlclient.so.15.0.0
同时，也试了一下Tomcat。
启动tomcat使用如下命令:
cd /usr/share/tomcat5/bin
java -jar bootstrap.jar
停止tomcat:
java -jar bootstrap.jar stop
今天真正理解什么是“
Free software”
What is Free Software?
“Free software” is a matter of liberty, not price. To understand the concept, you should think of “free” as in “free speech”, not as in “free beer”.
Free software is a matter of the users' freedom to run, copy, distribute, study, change and improve the software. More precisely, it refers to four kinds of freedom, for the users of the software:
The freedom to run the program, for any purpose (freedom 0).
The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
The freedom to redistribute copies so you can help your neighbor (freedom 2).
The freedom to improve the program, and release your improvements to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.
大约有10年没写过c程序了。由于工作需要，我又重新开始学习c。
今天解决两个问题：
1.段错误
原来字符串数组在使用前必须为它分配内存，这跟java可不一样。用calloc就可以。
2.警告：隐式声明与内建函数 ‘calloc’ 不兼容
加入#include "stdlib.h" 就可以了。
struct sockaddr {
unsigned short sa_family; /* address family, AF_xxx */
char sa_data[14]; /* 14 bytes of protocol address */
};
sa_family是地址家族，一般都是“AF_xxx”的形式。好像通常大多用的是都是AF_INET。
sa_data是14字节协议地址。
此数据结构用做bind、connect、recvfrom、sendto等函数的参数，指明地址信息。
但一般编程中并不直接针对此数据结构操作，而是使用另一个与sockaddr等价的数据结构
sockaddr_in（在netinet/in.h中定义）：
struct sockaddr_in {
short int sin_family; /* Address family */
unsigned short int sin_port; /* Port number */
struct in_addr sin_addr; /* Internet address */
unsigned char sin_zero[8]; /* Same size as struct sockaddr */
};
struct in_addr {
unsigned long s_addr;
};
sin_family指代协议族，在socket编程中只能是AF_INET
sin_port存储端口号（使用网络字节顺序）
sin_addr存储IP地址，使用in_addr这个数据结构
sin_zero是为了让sockaddr与sockaddr_in两个数据结构保持大小相同而保留的空字节。
s_addr按照网络字节顺序存储IP地址
sockaddr_in和sockaddr是并列的结构，指向sockaddr_in的结构体的指针也可以指向
sockadd的结构体，并代替它。也就是说，你可以使用sockaddr_in建立你所需要的信息,
在最后用进行类型转换就可以了bzero((char*)&mysock,sizeof(mysock));//初始化
mysock结构体名
mysock.sa_family=AF_INET;
mysock.sin_addr.s_addr=inet_addr("192.168.0.1");
……
等到要做转换的时候用：
（struct sockaddr*）mysock
---------send to--------
#include "stdio.h"
#include "sys/socket.h"
#include "netinet/in.h"
int main(void)
{
struct sockaddr_in sockin;
int sockId = 0,ret = 0;
char* buf;
sockId = socket(AF_INET,SOCK_DGRAM,0);
if(sockId < 0)
{
printf("Socket Failed!\n");
return 1;
}
memset(&sockin,0x0,sizeof(sockin));
sockin.sin_family = AF_INET;
sockin.sin_port = htons(1234);
sockin.sin_addr.s_addr = inet_addr("192.168.2.4");
//memset(&buf,'A',100);
buf = "This is message from server";
ret = sendto(sockId,buf,100,0,(struct sockaddr *)&sockin,sizeof(sockin));
if(ret != 100)
{
printf("Sendto failed!\n");
return 1;
}
close(sockId);
printf("Sendto succeed!\n");
return 0;
}
-----------receive----------
#include "stdio.h"
#include "sys/socket.h"
#include "netinet/in.h"
int main(void)
{
struct sockaddr_in sockin;
int sockId = 0,ret = 0;
char buf[100];
sockId = socket(AF_INET,SOCK_DGRAM,0);
if(sockId < 0)
{
printf("Socket Failed!\n");
return 1;
}
memset(&sockin,0x0,sizeof(sockin));
sockin.sin_family = AF_INET;
sockin.sin_port = htons(1234);
sockin.sin_addr.s_addr = INADDR_ANY;
ret = bind(sockId,(struct sockaddr *)&sockin,sizeof(sockin));
if(ret < 0)
{
printf("bind failed!\n");
return 1;
}
ret = recvfrom(sockId,buf,100,0,NULL,NULL);
if(ret < 0)
{
printf("Recvfrom failed!\n");
return 1;
}
printf("Recvfrom result=%d\n",ret);
close(sockId);
printf("%s\n",buf);
return 0;
}
http://www.knowsky.com/366521.html
在实际的任何一个系统中，查询都是必不可少的一个功能，而查询设计的好坏又影响到系统的响应时间和性能这两个要害指标，尤其是当数据量变得越来越大时，于是如何处理大数据量的查询成了每个系统架构设计时都必须面对的问题。本文将从数据及数据查询的特点分析出发，结合讨论现有各种解决方案的优缺点及其适用范围，来阐述J2EE平台下如何进行查询框架的设计。
Value List Handler模式及其局限性
在J2EE应用中，对于大数据量查询的处理有许多好的成功经验，比如Value List Handler设计模式就是其中非常经典的一个，见图1。该模式创建一个ValueListHandler对象来控制查询的执行以及结果集的缓存，它通过DAO(Data Access Object)来执行查询，并将数据库返回的结果集（传输对象Transfer Object的集合）缓存起来，接下来的客户端查询请求将直接从缓存中获得。它的特点主要体现在两点：服务器端缓存数据，每次只返回客户端本次操作所需的数据，通过这两个措施来减少数据库的访问次数以及增加客户端的响应速度，达到最优的查询效果。当然，这里面隐含一个前提就是客户端采用分页的方式来浏览数据。关于该模式的具体介绍，请参考[Core J2EE Patterns]一书。
但是在实际的应用过程中，会发现该模式存在一定的局限性，其实可以说是该模式应用具有一些前提条件：
1、由于缓存是以内存来换性能，这对于小数据量会工作得很好，但是假如结果集很大，内存消耗将会非常严重。同时，消耗在处理结果集上的时间也会越来越长，比如要循环读取记录集中的数据，然后依次填充每个传输对象，想想看几百万条数据这样处理起来肯定让人不能忍受。过长的处理时间不仅降低反应速度，同时还会占用宝贵的数据库连接资源，造成其它地方无连接可用。虽然，在DAO模式中利用CachedRowSet，Read Only RowSet ，RowSet Wrapper List等策略（详见参考资料）来代替Transfer Object Collection策略，有效地提高了处理速度，但是仍然存在着在大集合数据中进行定位、遍历等问题。试想一想，即使在CachedRowSet中的absolute(2000000)也是非常费时的操作。所有这一切的根源就在于缓存是一次性读取所有的数据，虽然有时你可以利用业务逻辑来强制性增加一些限制条件（比如产品查询必须选择大类和次类），但这种限制往往是不牢靠的或者说只是一时的权宜之计。也有人提出，可以不必缓存所有的查询结果，而采取只缓存部分结果集，比如500，1000条，但这样一来，就涉及到复杂的查询数据是否越界的控制，增加了复杂度，同时也不易实现。
2、既然使用缓存，那就不得不面对一个数据更新的问题，使用缓存，实际上就假定了在数据缓存期间，数据库中的数据不会改变，或者这些改变可以不被反映出来。但是，在很多场合下（比如常见的业务系统中）这些数据库中的数据经常会发生变化，而且这些改变需要及时反映给客户端。
3、缓存其实存在一个基本前提，就是缓存的数据会被客户端反复查询使用，具体到分页查询就是客户会选择不同的页数来查看数据。假如客户端的查询条件始终变化，或者用户基本上只关心第一页的数据（仔细琢磨一下用户的习惯，这在很多中应用场合都很常见），那缓存就失去了应有的意义，变得多此一举了。
数据分析
所以说，在决定是否应用某种设计模式前，我们需要对被查询数据的特点以及这些数据以何种方式被使用（查询的特点）进行一个分析，根据不同的结论来决定采用何种处理策略。而且，数据本身的特点和被使用的方式往往交织在一起，需要综合起来考虑，但这其中主要的考量点还是数据查询的特点。
一般来说，可以从以下几个方面来分析数据：
1、 数据量大。
这是我们今天讨论的数据的一个最基本特点，这个特点在查询框架设计时要引起足够的重视。
注重：大数据量的查询是指查询时匹配条件的数据量大，而不是指表中的数据量大，虽然大部分时候这两者都是一致的。因为在某些情况下，业务逻辑可以限制或者只需要一次获取很少量的数据，而查询的表中的数据量却可能很大，那这种情况就不属于本文的讨论范围。
2、 关联复杂，多表关联。
越是简单的数据可能关联越少，而越是复杂的数据往往都是多表关联，这样很多时候你需要将这几张表作为一个整体来考虑。
3、 变化频率。
从这个角度出发，可以大致将数据分为以下几类：几乎不变化的睡眠数据；有规律定时更新的数据，比如招聘网站的职位信息；经常性无规律更新的数据。
4、 成长性。
数据是否具有成长性，要预见数据的成长性，并在现有方案中考虑这种成长性，避免到时候查询框架的重新设计，象大部分的业务数据都具有这种成长性。
注重：这里也要非凡注重区分数据本身的成长性和数据查询的成长性，这看似等同的两者其实还是存在很大的区别。就拿招聘网站来说，有效职位的数据肯定是一天天在增加，具有高成长性，但是在某个区间（比如一个月，一个星期）内的有效职位查询则变化不会太大，不具有成长性。而后者却往往是实际系统中最常碰到的查询情况。
5、 数据查询的频率和方式。
所有的数据查询不可能被等同地使用，你要分清楚系统中的几个要害查询，这些查询使用频率高，响应要快。试想一想，假如一个电子商务系统的产品查询每次都要让顾客等上十秒钟，结果就可想而知。
用户的使用习惯分析
除了对数据查询本身需要进行分析之外，我们还需要去分析一下用户如何来使用或者看待这些数据，用户的使用习惯如何。有人可能觉得这作用不大，或者很难去分析，其实查询的最终使用者是用户，他们的一些习惯会很大程度上左右你的设计。
1、 用户关心数据哪些方面的特性，不关心哪些方面的特性。
上面我们分析了数据本身的许多特性，那用户对其中哪些特性最敏感呢？比如说对脏数据非凡不能接受，那我们就必须在查询框架设计时非凡照顾到这一点。因为再好的框架设计都不可能在每个方面都能达到最优的效果，当必须有所取舍的时候，我们就要明白哪些特性是客户最关心的。
2、 用户如何来使用数据。
现在一般查询的客户端都采用分页的方式，一个查询可能会存在十几页甚至几十页结果。对于某些查询，用户可能往往只关心第一页或者前几页的结果，比如用户需要查询出最近完成的工单，而对于另外一些查询，用户可能对所有页结果都很关注，比如用户查询出最近三天新增的招聘职位。这不同类型的查询在查询框架设计的时候都需要有所考虑并给予不同的处理策略。
查询框架的设计
对数据及用户使用习惯进行了仔细的分析，接下来就可以根据这些分析来设计你的查询框架了。在J2EE架构下，对于大数据量的查询主要采取以下两种方法：
基于缓存的方式：
从数据库得到全部（部分）数据，并将其在服务器端进行缓存，接下来的客户端请求，将直接从缓存中取得需要的数据。这其实就是Value List Handler模式的原理，它主要适用于数据量不是非常大，变化不是很频繁（或者变化频繁但是有规律）且不具有成长性的情况，比如招聘网站或者电子商务网站的大部分查询就非常适合采取这种方式。
采用这种方式，要非凡注重第一次查询问题，避免响应性能达不到要求，因为每个查询第一次都需要连接数据库，从中获取数据并缓存起来，所以第一次查询会比接下来的查询都显得更慢一些。
对于数据的缓存，有以下几种实现方式：
? 直接缓存在服务器端
Value List Handler模式就采取这种方式，并且可以根据不同的情况采取不同的缓存策略，比如Transfer Object集合，CachedRowSet等，这取决于你的DAO实现策略。
? 用临时表来保存查询结果
WLDJ（www.sys-con.com/weblogic/）杂志2004年第7期上有一篇名为“Handling Large Database Result Sets”的文章，它具体介绍了如何利用临时表来改良Value List Handler模式以支持大型的J2EE应用。
当然除了以上这些方法以外，实现缓存也可以求助于操作系统的特定实现，以前我在IBM DW发表过一篇探讨MMF在Java中应用的文章（见参考资料），可惜未有深入，有爱好的朋友可以参考一下。
在使用Value List Handler模式时，要非凡注重以下几点：
1、 该模式一般和DAO模式搭配使用。
2、 该模式有POJO，stateful session bean两种实现策略。
3、 假如采取stateful session bean实现策略，则默认该缓存的时间长度为整个用户会话。
前面我们也提到过，假如数据不是绝对不变的，那缓存就面临更新的问题，一旦更新就可能存在着数据不一致，假如恰巧客户也希望能够看到变化的效果，这个时候就需要采取某种措施来保证这种一致性。常见的措施可以是设置一个标志位，每次发生数据更新后都将其对应的标志位更新，查询时假如发现标志位更新了，就直接从数据库获取数据，而不是从缓存中获取数据。另外一种方式就是数据更新的同时主动去清空session中的缓存，假如采用stateful session bean实现策略的话。
当然，采取缓存方式的大数据量查询一般来说都不大可能碰到设置更新标志位的问题，因为这种应用方式决定了数据不大可能变化，或者数据变化不要求马上反应给用户。比如招聘网站新增加了一些职位信息，假如这些更新恰巧发生在某些用户的会话期间，且没有设置更新标志位，那这些新增信息就不会反应到用户的查询结果中，这种处理方式也是可以接受的。
经过UI工程师的努力，我们的软件变得更加美观。
http://bbs.8s8s.com/linux/linux7571.htm
高速路由器的系统交换能力与处理能力是其有别于一般路由器能力的重要体现。目前，高速路由器的背板交换能力应达到40Gbps以上，同时系统即使暂时不提供OC-192/STM-64接口，也必须在将来无须对现有接口卡和通用部件升级的情况下支持该接口。在设备处理能力方面，当系统满负荷运行时，所有接口应该能够以线速处理短包,如40字节、64字节，同时，高速路由器的交换矩阵应该能够无阻塞地以线速处理所有接口的交换，且与流量的类型无关。
指标之一： 吞吐量
吞吐量是路由器的包转发能力。吞吐量与路由器端口数量、端口速率、数据包长度、数据包类型、路由计算模式（分布或集中）以及测试方法有关，一般泛指处理器处理数据包的能力。高速路由器的包转发能力至少达到20Mpps以上。吞吐量主要包括两个方面：
1. 整机吞吐量
整机指设备整机的包转发能力，是设备性能的重要指标。路由器的工作在于根据IP包头或者MPLS 标记选路，因此性能指标是指每秒转发包的数量。整机吞吐量通常小于路由器所有端口吞吐量之和。
2. 端口吞吐量
端口吞吐量是指端口包转发能力，它是路由器在某端口上的包转发能力。通常采用两个相同速率测试接口。一般测试接口可能与接口位置及关系相关，例如同一插卡上端口间测试的吞吐量可能与不同插卡上端口间吞吐量值不同。
指标之二：路由表能力
路由器通常依靠所建立及维护的路由表来决定包的转发。路由表能力是指路由表内所容纳路由表项数量的极限。由于在Internet上执行BGP协议的路由器通常拥有数十万条路由表项，所以该项目也是路由器能力的重要体现。一般而言，高速路由器应该能够支持至少25万条路由，平均每个目的地址至少提供2条路径，系统必须支持至少25个BGP对等以及至少50个IGP邻居。
指标之三：背板能力
背板指输入与输出端口间的物理通路。背板能力是路由器的内部实现，传统路由器采用共享背板，但是作为高性能路由器不可避免会遇到拥塞问题，其次也很难设计出高速的共享总线，所以现有高速路由器一般采用可交换式背板的设计。背板能力能够体现在路由器吞吐量上，背板能力通常大于依据吞吐量和测试包长所计算的值。但是背板能力只能在设计中体现，一般无法测试。
指标之四：丢包率
丢包率是指路由器在稳定的持续负荷下，由于资源缺少而不能转发的数据包在应该转发的数据包中所占的比例。丢包率通常用作衡量路由器在超负荷工作时路由器的性能。丢包率与数据包长度以及包发送频率相关，在一些环境下，可以加上路由抖动或大量路由后进行测试模拟。
指标之五：时延
时延是指数据包第一个比特进入路由器到最后一个比特从路由器输出的时间间隔。该时间间隔是存储转发方式工作的路由器的处理时间。时延与数据包长度和链路速率都有关，通常在路由器端口吞吐量范围内测试。时延对网络性能影响较大, 作为高速路由器，在最差情况下, 要求对1518字节及以下的IP包时延均都小于1ms。
指标之六：背靠背帧数
背靠背帧数是指以最小帧间隔发送最多数据包不引起丢包时的数据包数量。该指标用于测试路由器缓存能力。具有线速全双工转发能力的路由器，该指标值无限大。
指标之七：时延抖动
时延抖动是指时延变化。数据业务对时延抖动不敏感，所以该指标通常不作为衡量高速路由器的重要指标。对IP上除数据外的其他业务，如语音、视频业务，该指标才有测试的必要性。
指标之八：服务质量能力
1．队列管理机制
队列管理控制机制通常指路由器拥塞管理机制及其队列调度算法。常见的方法有RED、WRED、 WRR、DRR、WFQ、WF2Q等。
排队策略：
● 支持公平排队算法。
● 支持加权公平排队算法。该算法给每个队列一个权（weight），由它决定该队列可享用的链路带宽。这样，实时业务可以确实得到所要求的性能，非弹性业务流可以与普通（Best-effort）业务流相互隔离。
● 在输入/输出队列的管理上，应采用虚拟输出队列的方法。
拥塞控制:
● 必须支持WFQ、RED等拥塞控制机制。
● 必须支持一种机制，由该机制可以为不符合其业务级别CIR/Burst合同的流量标记一个较高的丢弃优先级，该优先级应比满足合同的流量和尽力而为的流量的丢弃优先级高。
● 在有可能存在输出队列争抢的交换环境中，必须提供有效的方法消除头部拥塞。
2．端口硬件队列数
通常路由器所支持的优先级由端口硬件队列来保证。每个队列中的优先级由队列调度算法控制。
指标之九：网络管理
网管是指网络管理员通过网络管理程序对网络上资源进行集中化管理的操作，包括配置管理、计账管理、性能管理、差错管理和安全管理。设备所支持的网管程度体现设备的可管理性与可维护性，通常使用SNMPv2协议进行管理。网管粒度指示路由器管理的精细程度，如管理到端口、到网段、到IP地址、到MAC地址等粒度。管理粒度可能会影响路由器转发能力。
指标之十：可靠性和可用性
1．设备的冗余
冗余可以包括接口冗余、插卡冗余、电源冗余、系统板冗余、时钟板冗余、设备冗余等。冗余用于保证设备的可靠性与可用性，冗余量的设计应当在设备可靠性要求与投资间折衷。 路由器可以通过VRRP等协议来保证路由器的冗余。
2．热插拔组件
由于路由器通常要求24小时工作，所以更换部件不应影响路由器工作。部件热插拔是路由器24小时工作的保障。
3．无故障工作时间
该指标按照统计方式指出设备无故障工作的时间。一般无法测试，可以通过主要器件的无故障工作时间计算或者大量相同设备的工作情况计算。
4．内部时钟精度
拥有ATM端口做电路仿真或者POS口的路由器互连通常需要同步。在使用内部时钟时，其精度会影响误码率。
在高速路由器技术规范中，高速路由器的可靠性与可靠性规定应达到以下要求：
① 系统应达到或超过99.999%的可用性。
② 无故障连续工作时间：MTBF>10万小时。
③ 故障恢复时间：系统故障恢复时间 < 30 mins。
④ 系统应具有自动保护切换功能。主备用切换时间应小于50ms。
⑤ SDH和ATM接口应具有自动保护切换功能，切换时间应小于50ms。
⑥ 要求设备具有高可靠性和高稳定性。主处理器、主存储器、交换矩阵、电源、总线仲裁器和管理接口等系统主要部件应具有热备份冗余。线卡要求m+n备份并提供远端测试诊断功能。电源故障能保持连接的有效性。
⑦ 系统必须不存在单故障点。
好几年没写过存诸过程了，都忘光了。今天由于需求，又写了一个。
create or replace procedure stat_app_traffic
as
queryhour varchar2(15);
lasthour number;
begin
lasthour:= to_number(to_char(sysdate,'HH24')) - 1;
if(lasthour=-1) then
queryhour:= to_char(sysdate-1,'YYYY-MM-DD ') || '23';
else
queryhour:= to_char(sysdate,'YYYY-MM-DD ') || lasthour;
end if;
insert into app_traffic(app,bytes,log_time)
select app,round(sum(bytes)/1024/1024,2),max(log_time) from
((select b.app,a.src_port port,a.out_bytes bytes,a.log_time
from raw_netflow a,app_config b
where a.src_port=b.port and a.protocol=b.protocol_id
and to_char(log_time,'YYYY-MM-DD HH24')=queryhour)
union
(select b.app,a.dst_port port,a.in_bytes bytes,a.log_time
from raw_netflow a,app_config b
where a.dst_port=b.port and a.protocol=b.protocol_id
and to_char(log_time,'YYYY-MM-DD HH24')=queryhour)) group by app;
commit;
end stat_app_traffic;
完成首页，实现了JFreeChart柱状图可钻取的功能。
读后，终于对BI的一些基本概念有比较清楚地认识。