发表于 | 阅读次数

突兀的出来一个libvirt的教程三，您可能会觉得奇怪，其实这是OneCoder以前写的一个小系列教程，原来发在51cto的博客上，前两篇已经发了过来，考虑到完整性，就把第三篇也发过来。前两篇地址：

之前已经介绍过了libvirt api的上手使用方式，这里再补充一些细节问题。

TLS安全认证访问：

之前我们给出的例子都是直接用tcp访问的，这就需要被访问的服务器开放tcp访问的端口，也就是说，任何机器只要知道了服务器的ip，都是可以访问上面的libvirt接口的。这是十分危险的，在生产环境中是不可取的。

所以，libvirt支持基于tls认证的安全访问协议。连接格式如下：

qemu+tls://10.4.54.10
或者
qemu://10.4.54.10(因为默认就是走tls的)

要想正常访问，必须在客户端和服务端配置证书，下面就介绍一个这个配置过程。

  1. 首先自然是证书生成工具的安装。libvirt官方推荐的工具是：GnuTLS。不过可惜，官网给出的地然居然不正确。GnuTLS项目，官网地址如下：

下载页面为：

这里介绍的windows环境下配置，所以进入页面：

下载即可。

  1. 解压下载的工具。通过命令行进入\bin目录(或者将该bin目录配置到环境变量的path即可在任意路径访问)：

  1. 首先为你的证书生成私钥：

Create a private key for your CA:

certtool --generate-privkey > cakey.pem

然后，为你证书进行自签名。

and self-sign it by creating a file with the signature details called ca.info containing:</p>

cn = Name of your organization
ca
certsigningkey

certtool --generate-self-signed --load-privkey cakey.pem   --template ca.info --outfile cacert.pem (Y)

先在当前路径下创建一个叫ca.info的文件，里面写上如上第一段内容，

然后执行第二段引用所示命令：

报错。这下头疼了。。笔者翻箱倒柜，翻江倒海找了一通。。实在没有找到答案。。。考虑到证书的制作过程中没有与机器相关的信息，所以，决定求助笔者非常不熟悉的linux。掏出putty，登录，重新执行上面第一个命令。生成私钥：

然后同样按照上面的方式进行签名，果然轻松成功！

此时已经可以删除ca.info文件了。继续生成证书，接下来开始生成服务端私钥：

certtool --generate-privkey > serverkey.pem

然后签名：

certtool --generate-certificate --load-privkey serverkey.pem  --load-ca-certificate cacert.pem --load-ca-privkey cakey.pem --template server.info --outfile servercert.pem

同样是依靠一个叫做server.info的文件。先创建改文件，写入如下格式内容：

organization = Name of your organization
cn = oirase
tlswwwserver
encryptionkey
signingkey

这里只有cn这个属性需要注意，他应该是当前主机的主机名：（

only the CN field matters, which as explained above must be the server's hostname）- (The CN must match the hostname which clients will be using to connect to the server. In the example below, clients will be connecting to the server using a URI of xen://oirase/, so the CN must be "oirase".)

如果不知道主机名，用ip当然也是可以的。那么你的访问就是通过IP访问了。：）

成功。

将服务端证书拷贝服务器的相应位置：

Finally we have two files to install:

serverkey.pem is the server's private key which should be copied to the server only as /etc/pki/libvirt/private/serverkey.pem.
servercert.pem is the server's certificate which can be installed on the server as /etc/pki/libvirt/servercert.pem.

最后是客户端的证书，过程类似，这里只列出主要过程和命令：

1、创建私钥:

certtool --generate-privkey > clientkey.pem

2、创建client.info模版文件:

country = GB
state = London
locality = London
organization = Red Hat
cn = client1
tlswwwclient
encryptionkey
signingkey

然后签名:

certtool --generate-certificate --load-privkey clientkey.pem \
  --load-ca-certificate cacert.pem --load-ca-privkey cakey.pem \
  --template client.info --outfile clientcert.pem

3、拷贝证书到客户端的指定位置（linux）:

cp clientkey.pem /etc/pki/libvirt/private/clientkey.pem
cp clientcert.pem /etc/pki/libvirt/clientcert.pem

其中client.info中国家等信息可根据你的情况指定。

至此，需要的证书已经都准备好了。证书有了，服务端也部署了。但是windows的客户端不知道该部署到什么地方？因为网上的说明给出的都是linux文件路径，没说windows下的情况。不过笔者相信libvirt的错误日志：）于是：

怎么样，位置有了吧。赶紧拷贝过去试试。</p>

有的同学可能发现，这里只给出了一个位置，我们有三个证书呢。别急，你看这个路径，比照网上给出的linux的路径格式：

Location Machine Description Required fields
/etc/pki/CA/cacert.pem Installed on all clients and servers CA's certificate (more info) n/a
/etc/pki/libvirt/ private/serverkey.pem Installed on the server Server's private key (more info) n/a
/etc/pki/libvirt/ servercert.pem Installed on the server Server's certificate signed by the CA. (more info) CommonName (CN) must be the hostname of the server as it is seen by clients.
/etc/pki/libvirt/ private/clientkey.pem Installed on the client Client's private key. (more info) n/a
/etc/pki/libvirt/ clientcert.pem Installed on the client Client's certificate signed by the CA (more info) Distinguished Name (DN) can be checked against an access control list (tls_allowed_dn_list).

其实基本已经可以猜出windows下的目录组织了。linux在的/etc目录，就想当于我们这里的..\libvirt目录，子目录的组织相同即可。

没猜出来也不用担心，最多我们复制一个证书尝试一次，错误信息会依次告诉你所有的路径的：）

再访问一下，成功~

补充说明一下关于动态链接文件的问题:

之前介绍的时候，笔者只提到说调用libvirt Java api需要一个virt.dll文件，这个文件笔者是拷贝的libvirt-0.dll文件改名而来，然后访问成功。

笔者后来发现，原来libvirt 安装目录的bin文件夹下的所有文件，其实都是该dll文件的依赖文件，当笔者将其他文件删除或转义的时候，依然会报找不到virt.dll文件的错误。所以，如果调用libvirt Java API开发，可以将所有的dll拷贝到一个指定位置，然后指定jna.library.path到该位置即可。

阅读全文 »

发表于 | 阅读次数

最近有段时间没有更新Netty的教程了，却发了一些其他的东西。可能有的朋友会问，难道这就完事了？不会的。两方面原因。第一、笔者也是需要工作的人，自然要完成好工作中的任务，这里面也有很多东西需要学习和研究，这也是我分享的方向和源泉。第二、想要掌握好Netty，周边的知识也不能少，这也是笔者在恶补的东西。所以，你完全可以把我最近分享的东西理解为为学习Netty所做的准备。

Java虚拟机定义了若干种程序运行期间会使用到的运行时数据区，其中有一些会随着虚拟机启动而创建，随着虚拟机退出而销毁。另外一些则是与线程一一对应的，这些与线程对应的数据区域会随着线程开始和结束而创建和销毁。

Stack栈

栈也叫栈内存，是Java程序的运行区，是在线程创建时创建，它的生命期是跟随线程的生命期，线程结束栈内存也就释放，对于栈来说不存在垃圾回收问题，只要线程一结束，该栈就Over。问题出来了：栈中存的是那些数据呢？又什么是格式呢？ 栈中的数据都是以栈帧（Stack Frame）的格式存在，栈帧是一个内存区块，是一个数据集，是一个有关方法(Method)和运行期数据的数据集，当一个方法A被调用时就产生了一个栈帧F1，并被压入到栈中，A方法又调用了B方法，于是产生栈帧F2也被压入栈，执行完毕后，先弹出F2栈帧，再弹出F1栈帧，遵循“先进后出”原则。 那栈帧中到底存在着什么数据呢？栈帧中主要保存3类数据：本地变量（Local Variables），包括输入参数和输出参数以及方法内的变量；栈操作（Operand Stack），记录出栈、入栈的操作；栈帧数据（Frame Data），包括类文件、方法等等。光说比较枯燥，我们画个图来理解一下Java栈，如下图所示：

图示在一个栈中有两个栈帧，栈帧2是最先被调用的方法，先入栈，然后方法2又调用了方法1，栈帧1处于栈顶的位置，栈帧2处于栈底，执行完毕后，依次弹出栈帧1和栈帧2，线程结束，栈释放。

根据Java虚拟机规范，Java虚拟机规范允许Java虚拟机栈被实现成固定大小的或者是根据计算动态扩展和收缩的。如果采用固定大小的Java虚拟机栈设计，那每一条线程的Java虚拟机栈容量应当在线程创建的时候独立地选定。Java虚拟机实现应当提供给程序员或者最终用户调节虚拟机栈初始容量的手段，对于可以动态扩展和收缩Java虚拟机栈来说，则应当提供调节其最大、最小容量的手段。 如果线程请求分配的栈容量超过Java虚拟机栈允许的最大容量时，Java虚拟机将会抛出一个StackOverflowError异常。

根据上面的分析，我们来构造一个StackOverflowError来加深理解：

/**
 * JVM参数配置
 * 
 * @author lihzh(OneCoder)
 * @alia OneCoder
 * @Blog http://www.coderli.com
 * @date 2012-7-31 下午9:04:26
 */
public class JVMParams {
	/**
	 * @author lihzh(OneCoder)
	 * @date 2012-7-31 下午9:04:27
	 */
	public static void main(String[] args) {
		getStackOverFlowError(0);
	}

	/**
	 * 通过递归调用，诱发StackOverFlowError
	 * 
	 * @author lihzh
	 * @alia OneCoder
	 */
	private static void getStackOverFlowError(int count) {
		if (count < 10000) {
			System.out.println("count:" + count);
			getStackOverFlowError(++count);
		}
	}
}

count:4388 Exception in thread “main” java.lang.StackOverflowError at sun.nio.cs.UTF_8.updatePositions(UTF_8.java:77) at sun.nio.cs.UTF_8$Encoder.encodeArrayLoop(UTF_8.java:564) at sun.nio.cs.UTF_8$Encoder.encodeLoop(UTF_8.java:619) at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:561) at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:271)

在递归调用4388遍时，出现stackoverflow异常。(该数据不稳定，大约在4300行左右)。

下面修改下虚拟机栈的大小再配置一下，根据我们之前的文章介绍。设置

-Xss1024k。

count:13404 Exception in thread “main” java.lang.StackOverflowError at sun.nio.cs.UTF_8.updatePositions(UTF_8.java:77)

发现确实有明显的变化。再增大一倍试试。

count:24618 count:24619 Exception in thread “main” java.lang.StackOverflowError

《Java虚拟机规范》中对于Stack还有一段描述：

如果Java虚拟机栈可以动态扩展，并且扩展的动作已经尝试过，但是目前无法申请到足够的内存去完成扩展，或者在建立新的线程时没有足够的内存去创建对应的虚拟机栈，那Java虚拟机将会抛出一个OutOfMemoryError异常。

我们再来，构造一个 OutOfMemoryError 异常。设置

-Xss170m

（具体临界值取决与测试机的系统环境，和JVM配置）。再跑一次，果然抛出：

Error occurred during initialization of VM java.lang.OutOfMemoryError: unable to create new native thread

这里网上给出了计算可以创建出最大线程数的计算公式：

MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = 线程数
MaxProcessMemory 指的是一个进程的最大内存
JVMMemory         JVM内存
ReservedOsMemory  保留的操作系统内存
ThreadStackSize      线程栈的大小

OneCoder在这里猜测，是否是当计算出的线程数 <1 时，便会抛出这样的异常。这个公式涉及到4个值，不过有的可以有据可查的。在32位系统下，MaxProcessMemory一般认识为2G。JVM内存我们可以通过-Xmx指定。保留的操作系统内存，网上说一般是120m左右，OneCoder这里无据可查，暂不考虑。

不过可以看到，栈空间的分配是用的JVM之外的部分(如果错误，还请指正。)，我们可以控制的是-Xmx的大小，所以OneCoder这里把-Xmx设置成10m(改小。)，测试-Xms180m的情形，果然可以成功运行了。

到这里，OneCoder其实认为研究还远未结束，OneCoder根据上面的公式和OneCoder的猜测，-Xss的最大值怎么也不应该这么小，当然这很可能是我猜测错了，但是真像是什么呢？。无奈一时间也无法验证，暂且就当存疑吧，希望随着对JVM的了解，能逐渐揭开一团。

OneCoder提醒：由此可见-Xss参数的设置是需要非常消息的，太大，则可能会无法创建足够的线程，太小，则可能无法进行足够深层次的递归。需要你对的你程序有足够的了解和把握的基础上，合理的优化栈的大小。

希望高手不吝赐教。感激不尽。

参考：

  • 《Java虚拟机规范》
  • 《慢慢琢磨JVM》
阅读全文 »

发表于 | 阅读次数

动手来为你的Eclipse增加一个能显示当前Eclipse使用的JVM配置的工具条吧。简单的很。

在eclipse根目录下建立一个文件，文件名options,不要加后缀直接保存，文件内容

org.eclipse.ui/perf/showHeapStatus=true

修改eclipse目录下的eclipse.ini文件，在文件起始部分添加如下内容：

-debug
options
-vm
javaw.exe

重启即可。

阅读全文 »

发表于 | 阅读次数

接上篇：《《OneCoder翻译 每个程序员必知的知识，UniCode和字符集(上)》

好吧，从技术上讲，可以，我相信他可以。事实上，早起的实现者想用high-endian和low-endian两种模式保存Unicode字符码，不论哪种方式都是他们特定的CPU最快的处理方式。呵呵，夜以继日，现在就有了两种保存Unicode的方式。

所以人们不得不在每个Unicode串前强制的加上奇怪的约定：FE FF，这被称作Unicode字节顺序标识(OneCoder注：Unicode Byte Order Mark)。如果你交换了高低位的顺序，那将变成FF FE，读取你字符串的也将知道需要交换每一个字节。啊，不过不是每个Unicode字符串的开头都有字节顺序标识。

曾经，人们认为这足够好了，但是有些开发者却开始抱怨，看那一堆一堆的的0。是啊，因为他们是美国的开发者，他们仅关注英语文本，很少使用U+ooFF以上的编码。当然，这也是因为他们是来自加利福尼亚的对此不屑的自由的嬉皮士。如果他们是德克萨斯州人，他们可能不会在意消化两倍容量的字节。然而，加利福尼亚人无法忍受为字符串消耗两倍的存储空间，并且不管怎样，那已经有许多使用各种各样ANSI和DBCS字节码保存的令人厌烦的文档，谁能来改变这一切？摩伊人(Moi)？出于这个原因，大部分人放弃Unicode若干年，事情又变得糟糕起来。

因此，发明了美妙的UTF-8规范。UTF-8是另一种保存Unicode编码的系统，那些神奇的U+数字，在内存中使用8位字节。在UTF-8系统中，从0-127的每个字符码用一个单字节保存。128以上的编码，使用2个或者6，甚至6个字节保存。

这种方式的优雅之处在于，得英文文字的保存在UTF-8和ASCII系统中完全一样，所以美国人没有表示任何问题。只是世界上剩下的人们不得不适应这个转变。特别的，Hello，Unicode码是：U+0048 U+0065 U+006C U+006C U+006F，将被保存为：48 65 6C 6C 6F，看！跟在ASCII中、ANSI中，甚至这个星球上每个OEM字符集中一致。现在，如果你有勇气去使用带有重音的字母或是希腊字母或是克林贡字母，你将不得不若干字节去保存一个字节码，但是美国人永远不会在意。(UTF-8还有一个很好的特性，就是旧的使用单独的0作为空结束符的字符串处理编码不会截断字符串。)

到目前为止，我已经讲解了三种Unicode的编码方式:传统的2个字节的保存方式，UCS-2(因为他有两个字节)或是UTF-16(因为他有16位)，同事你仍必须认出是否他是high-endian的UCS-2还是low-endian的UCS-2。还有流行的新的UTF-8标准，该标准可以在你需要考虑英语和那些完全没有考虑ASCII以外编码的脑残程序的一致性方面，很好的工作。

事实上，还有很多Unicode的编码方式。例如：UTF-7, 和UTF-8很类似，只是最高位永远是0。所以，如果你需要给某些要求苛刻的，认为7位已经足够的警察email系统传递Unicode，感谢你仍可以无损的压缩字节。还有UCS-4，用4个字节保存每个字符码。好处就是每个字符都占用同样多的字节，但是，天啊，德克萨斯人们又无法忍受浪费这么多内存。

其实我们现在考虑的用Unicode展现的字符都是那些理想的字符，这些Unicode字符码同样也可以在任何的老派的编码系统中编码出来。例如：你可以给Hello进行Unicode编码(U+0048 U+0065 U+006C U+006C U+006F)，进行ASCII编码或者古老的OEM希腊编码，或者希伯来ANSI编码，或者其他成百上千的编码方式。但是有一点需要注意：有一些字符无法展现！如果在Unicode字符码中没有与之对应的编码，例如，你常用遇到问号：？或者 � ，我改如何去做。

有成百上千的传统的编码仅仅可以保存正确编码，其余的全部转换成问号。一些流星的英语编码方式是Winodws-1252(Windows9.x系列的西欧语言的编码标准)和ISO-8859-1，又叫Latin-1(也是处理西欧语言的有效方式)。但是，如果尝试用这些编码保存俄罗斯或者希伯来语，你将会得到一堆的问号。UTF7,8,16和32都有很好特性，可以保存任何正确的编码。

编码最重要的事实

如果你已经完全忘记了我前面阐述的东西，请记住一个重要的事实。如果他不知道你使用的编码方式，那将无法工作。你不可能把你的头埋在沙子里，然后假装说”普通”(plain)文本是ASCII的。

没有所谓纯文本的东西。

如果你有一段字符串，不论在内存里还是文件里或是在email中，你必须要知道他的编码方式，否则你将无法解析和正确展示他。

几乎所有的关于”我的网站看起来乱码了”或是”当我在邮件里用带音调的字母的时候她就无法阅读了”这样愚蠢的问题，都是发生在那些不懂得上面关于编码的简单的事实的幼稚的程序员身上：如果你不知道字符串是用UTF-8或是ASCII或是ISO8859-1(Latin 1)还是Windows1252(Western European)编码，你就无法正确的展现它，甚至不知道他的结尾在哪里。有超过一百的编码和高127位的处理方式，一切猜测都没有用。

那么，我们怎么保存字符串所使用的编码类型的信息呢？呵呵，这有一个标准的方式。例如对于邮件信息，你希望在邮件头里看到类似这样的一串字符串：

Content-Type: text/plain; charset=”UTF-8”

对于网页，原来的想法是web服务器在web页面本身返回一个类似的 Content-Type头信息，不是在HTML页面本身，而是作为相应头在HTML页面之前返回。

这引发了一些问题。试想一下，你有一个大型的web服务器，里面有很多站点和非常多的页面，为说各种语言的人们服务，并且页面使用了适合他们的编码来读微软的FrontPage页面编码。Web服务器本身无法知道每个文件编写时的真正编码，所以他无法发送Content-Type头信息。

所以，如果你可以通过一些特殊的标签，把Context-Type信息放到HTML页面本身那将非常方便。当然，这会使那些有纯粹主义者疯狂…

在你知道HTML文件编码之前，你怎样去阅读他？幸运的是，几乎所有通常使用的编码在32-127之前的处理方式都是一样的。所以，你总可以在使用特殊符号之前，从HTML页面中得到编码信息：

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

然而，这个元标签必须是头标记中的第一个元素，因为浏览器在看到这个标签时，会立即停止原有的解析，而改为采用你指定的编码进行解析。

如果浏览器在http头和html标签中都没有找到Context-Type标记，会怎么做呢？IE浏览器的做法比较有趣：他试图基于各种字节在不同语言的典型的文本、典型编码中的出现频率去猜测你的语言和编码。因为，各种老的8位的编码，习惯把他们本地的字母放在128-255之间不同的范围内，同时因为每种人类语言都有自己的不同的字母使用典型直方图，所以，这种猜测确实在某种程度中可行。这的确有写些诡异，以至于使一个不知道需要在header中添加Content-Type信息的天真web页面的开发者，发现不了页面的问题。直到有一天，他们开发了一些不完全符合字符频率分部的本地语言的页面，IE浏览器认为是韩语并且据此展现，这说明，Postel法案关于”保守的给予，自由的获取”(OneCoder注：conservative in what you emit and liberal in what you accept)的观点，对于工程理论来说是荒谬的。那么，该网站可怜的读者该怎么办？本来网站是用保加利亚语写的，却用韩语展现。(甚至还是无法理解的韩语)。如果他知道，他可以通过查看->编码菜单尝试不同的编码，(那里对于东欧的编码就有一大堆)，直到页面开始显示正常。当然，大部分人们并不知道去这么做。

在我们公司发布的网站管理软件，CityDesk的最新版中，我们决定采用UCS-2来存储Unicode，这正式VistualBasic,COM,和WindowsNT/2000/XP采用的表示本地字符串的方式。在C++的代码中，我们用wchar_t(“wide char”)来声明字符串，而非使用char,并且使用wcs函数而非str函数。(例如:wcscat和wcslen来代替strcat和strlen)。为了在C语言中声明一个UCS-2的字符串，你必须在前面加上一个L，变成:L”Hello”。

当CityDesk发布网页版的时候，变成了这些年浏览器普遍支持良好的UTF-8编码。这就是Joel on Software 网站29种不同语言版本的编码方式，我还没有听说任何一个人有编码问题。

这篇文章已经好长了。(OneCoder注：确实太长了，累吐血了。) 我不可能面面俱到的介绍关于字符编码和 Unicode的一切，但是，我仅希望，如果你读到了这里，你可以拥有足够知识去开发程序了。用抗生素治病，而不要用水蛭和符咒了，剩下的，就靠你自己了，孩子。

OneCoder注：头一次翻译，感觉翻译的很生硬，错误也再所那面，望多多指教。</div>

阅读全文 »

发表于 | 阅读次数

今天在处理了一个编码的问题，激发了笔者强烈的弄清编码问题的好奇心。遂先有了前面强烈推荐的文章：字符编码介绍 通俗易懂 强烈推荐。下面是上篇文章中提到的延伸阅读里，第一篇文章的翻译。水平有限，各位看官，勉强理解一下，错误之处还望指出。

你是否曾迷惑于Content-Type标签？你知道你需要写在HTML文件中，但是却不知道他是做什么的。

你是否层收到来自保加利亚的朋友的邮件，主题却是：”???? ?????? ??? ????”。

我曾经吃惊的发现有许多程序员没有真正理解字符集，编码，Unicode等相关问题的含义。若干年前，FogBUGZ的一个测试人员对他们是否可以处理日文的邮件感到好奇。日语？他们有日文邮件？这个我不清楚。当我近距离了解到我们层用来解析MIME邮件的商业版的ActiveX系统时，我发现他对字符集的处理完全是错误的。所以，我们不得不去写”夸张”的代码去恢复他做的错误的转换，然后重做正确的转换。当我发现，另一个商业版的包在字符的实现上也犯了同样错误。我理解这个包的开发者的想法，他们”不能做任何事”。就像许多开发者一样，他仅希望这个问题会莫名其表的消失。

但是事实不会那样。当我发现，著名的web开发工具PHP，也几乎完全忽略了字符编码的问题，轻率的用8位表示字符，从而使得开发出 一个好的国际化的web应用几乎不可能的时候，我认为够了，这够了。

所以在这里，我声明：如果你是一个工作在2003年的程序员，(OneCoder注：这篇文章写于2003年。)并且你不知道基本的字符，字符集，编码和Unicode的知识，并且被我抓到，我将要惩罚你在潜艇里拨洋葱皮6个月，我发誓，我会做到。并且，更重要的是：他并不难。

在这篇文章里，我将要告诉你每个开发人员必须知道的事情。告诉你，普通文本(plain text)=ascii=字符(characters) 都是8位的，不仅是错误的，而是无可救药的错误的。并且，如果你仍在以这样的理解编程，那较之于一个医生不相信细菌有过之而无不及。在读完这篇文章之前，不要在动手写任何代码了。

在我开始之前，我需要提醒你，如果你是少数的了解国际化的人，你可能会觉得我整篇的讨论都很浅显。我确实尽力的试图将门槛降到最低，以使每个人可以理解这是什么并且能满怀希望写出处理各种语言的代码，而不仅仅是不包含音调的英文。同时，我还要提醒你，字符的处理仅仅是开发出国际化产品的一小部分工作，然而我一次只能说明一个问题，所以今天，我会讲解字符集。

历史回顾

最简单的理解这些事情的方式自然是从头去回顾。

你可能会认为，我将会讲EBCDIC（OneCoder注：Extended Binary Coded Decimal Interchange Code） 这样非常古老的字符集。呵呵，我不会的。EBCDIC 跟你的生活没太大关系，我们不会去讲那么古老的东西。

追溯到Unix诞生，K&R发明了C语言的时代，任何东西都很简单。EBCDIC 就是在那个环境下产生的。

当时包含的字符仅仅是，古老的无重音的英文字符，我们给这些字符以一些代码，称为ASCII。ASCII可以通过32-127之间的数字，来代表每一个字符。例如：空格(space)是32，A是65等等。这可以正好用7位进行存储。在那个时代，大部分的计算机都是采用8位的，所以，你不仅仅可以保存每一个可能的ASCII字符，你还可以有完整的一位去做任何你想做的事情：比如，WordStar(OneCoder注：可能是文字处理软件)，用最高位来标识最后一个单词的最后一个字母，这也迫使WordStar仅可以处理英文文章。32以下的代码被成为不可打印的字符，是用来诅咒的。呵呵，开玩笑了。他们其实是操作字符，比如，代码7可以是你的计算机发出嘟嘟的声音；12可以是换行等。

如果你是说英语的，那么一切都很好。

因为一字节有8位，很多人就会想，”我们可以用128-255来代表我们想要的东西”。不过我问题是，很多人都同时有同样的想法，他们又都有自己对于128-255这些字符的规划。IBM-PC创造了OEM字符集，可以表示一些带有音调的欧洲语言和一些可以用来化字符的线，水平线，垂直线，带有拐角的水平线等。你可以用这写线条字符，绘制出一些整洁的表格和线条，你仍然可以在干洗店里那些8088系列的计算机里看到这些字符。事实上，当美国以外的人们开始购买PC机开始，各种各样的OEM字符集开始被设计出来，并且都是用高位的128个字符为自己所用。例如，在某些PC上，字符码130代表é， 在以色列的一些计算机上，130代表希伯来字母ג。所以，当美国人发送résumés给以色列人的时候，以色列人可能会收到rגsumגs。在很多情况下，比如俄罗斯，同样有很多各种各种的设计针对高位的128个字符，所以你可能无法准确的翻译俄罗斯文档。

终于，这种人人自由的OEM方式，随着ANSI(OneCoder注：American Engineering Standards Committee)标注的出台被终结。根据ANSI标准，大家都遵循低位的128字符的定义，跟ASCII的定义一样，但是对于高位的128字符的处理，根据大家所处环境的不同，有各种各样方式。这些不同的系统被称作代码页。(OneCoder注：原文为code pages，可能需要翻墙访问)。因此，比如在以色列DOS使用的代码页为862，希腊为737。他们都有相同的低128位的，但是高128位不同，保存着各自有趣的字符。国际化版本的MS-DOS，有需要这样的代码页，处理了从英语到冰岛语等语言，甚至有些多语言的代码页，可以处理世界语和加利西亚语在同一台计算机上。Wow。然而，想在同一个计算机里处理希伯来语和希腊语是完全不可能的，除非你编写自定义的程序，通过位图来展示一切。因为，希伯来语和希腊语需要不同的代码页对高的128位有不同的解释。

同时，在亚洲，更夸张的是，亚洲的字母表有成千上万的字符，完全不可能用8位字符去表示。不过，这个问题有一种不寻常的混乱的解决方式，DBCS(double byte character set)，双字节字符集，在这个字符集中，有些字母用一个字节存储，有些用两个。这使得对一个字符串进行前移操作比较简单，然而却几乎无法进行该死的后移操作。(OneCoder注：这里的意思笔者也不是很明白。原文：It was easy to move forward in a string, but dang near impossible to move backwards.)。开发者被告之不要使用s++和s–进行后移和前移，而是调用Windows' AnsiNext和AnsiPrev函数，这些函数知道该如何处理这些混乱的东西。

然而，很多人仍然假定一个字节是一个字符并且一个字符是8位，只要你不将字符串从一个计算机移到另一个或者只说一种语言，这些永远是对的。然而，从Internet诞生那刻起，将字符串从一个计算机传递到另一个计算机是非常司空见惯的事情，因此这些混乱的事情一下都发生了。幸运的是，Unicode诞生了。

Unicode

Unicode是一个勇敢的尝试，用一个单一的字符集去包含这个星球所有合理编写的系统甚至像克林贡语这样假定出来的系统。一些人错误的认为Unicode是简单的16位编码，任何字符都需要用16位来表示，因此一共有65536个字符。这事实上是错误的。这是对Unicode最常见的误解，所以如果你也是那样认为的，不必难过。

事实上，Unicode有一种不一样的方式去考虑字符的问题，你必须去理解Unicode的思考方式，否则你无法理解任何事。

到目前为止，我们已经假定，一个字母映射到一些保存在磁盘或者内存中的字节：A -> 0100 0001

在Unicode中，字母A是非实际的。它在天堂中游离：A。

这个虚幻的A不同于B，也不同于a，但是与A和A相同。这种不同字体的A是同样的字符，但是与小写的a不同的想法，看起来并不难以理解，但是在一些语言中恰恰指出了一个字母可能引起争议的所在。德语中的ß是真实的字母还是仅仅是ss的有趣的书写方式？如果一个词尾的字母的外形发生改变，他是一个不同的字母吗？希伯来语说是，阿拉伯语说不是。不管如何，Unicode联盟中聪明的人们在过去十年中，在激烈的争论中，想出了解决方案，你不必再去担心那些事。他们已经完全解决了这个问题。

在任何字母表中的任何想象中的字符都被Unicode联盟赋予一个魔数，比如：U+0639。这个魔数被成为字符码(Onecoder 注：code point)。U+代表Unicode，数字是十六进制的。U+0639 **是阿拉伯字母Ain。英语中的A是U+0041。你可以在Windows2000/xp的字符映射工具或者访问unicode**官网找到这些映射。

事实上，对于Unicode能表示的字符数没有严格的限制，他们已经超过了65536，所以不是每个Unicode字母都可以压缩到用两个字节表示，这很虚幻。

OK，现在我们有一个字符串：Hello，在Unicode中对应5个字符码：U+0048 U+0065 U+006C U+006C U+006F。是一组字符码。我们还没有提到任何关于这些字符码在内存中如何保存以及在email中如何展现的事。

编码

这就是编码的来历。最初的关于Unicode的编码想法是，我们就干脆用两个字节保存这些数字，这个想法导致了两字节的神话。因此，Hello变成了：00 48 00 65 00 6C 00 6C 00 6F。

正确了？别这么早下结论。难道它不可能是：48 00 65 00 6C 00 6C 00 6F 00 吗？

好吧，从技术上讲，可以，我相信他可以。事实上，早期的实现者想用high-endian和low-endian两种模式保存Unicode字符码，不论哪种方式都是他们特定的CPU最快的处理方式。呵呵，夜以继日，现在就有了两种保存Unicode的方式。

未完待续……

阅读全文 »

发表于 | 阅读次数

如果您一直关注OneCoder，我们之前有两篇文章介绍关于Netty消息连续收发的问题。( 《Java NIO框架Netty教程（五）- 消息收发次数不匹配的问题 》、《 Java NIO框架Netty教程(七)-再谈收发信息次数问题 》)。如果您经常的”怀疑”和思考，我们刚介绍过了Object的传递，您是否好奇，在Object传递中是否会有这样的问题？如果Object流的字节截断错乱，那肯定是会出错的。Netty一定不会这么傻的，那么Netty是怎么做的呢？

我们先通过代码验证一下是否有这样的问题。（有问题的可能性几乎没有。）

/**
	 * 当绑定到服务端的时候触发，给服务端发消息。
	 * 
	 * @author lihzh
	 * @alia OneCoder
	 */
	@Override
	public void channelConnected(ChannelHandlerContext ctx, ChannelStateEvent e) {
		// 向服务端发送Object信息
		sendObject(e.getChannel());
	}

	/**
	 * 发送Object
	 * 
	 * @param channel
	 * @author lihzh
	 * @alia OneCoder
	 */
	private void sendObject(Channel channel) {
		Command command = new Command();
		command.setActionName(&quot;Hello action.&quot;);
		Command commandOne = new Command();
		commandOne.setActionName(&quot;Hello action. One&quot;);
		Command command2 = new Command();
		command2.setActionName(&quot;Hello action. Two&quot;);
		channel.write(command2);
		channel.write(command);
		channel.write(commandOne);
	}

打印结果：

Hello action. Two Hello action. Hello action. One

一切正常。那么Netty是怎么分割对象流的呢？看看ObjectDecoder怎么做的。 在ObjectDecoder的基类LengthFieldBasedFrameDecoder中注释中有详细的说明。我们这里主要介绍一下关键的代码逻辑：

@Override
    protected Object decode(
            ChannelHandlerContext ctx, Channel channel, ChannelBuffer buffer) throws Exception {

        if (discardingTooLongFrame) {
            long bytesToDiscard = this.bytesToDiscard;
            int localBytesToDiscard = (int) Math.min(bytesToDiscard, buffer.readableBytes());
            buffer.skipBytes(localBytesToDiscard);
            bytesToDiscard -= localBytesToDiscard;
            this.bytesToDiscard = bytesToDiscard;
            failIfNecessary(ctx, false);
            return null;
        }

        if (buffer.readableBytes() < lengthFieldEndOffset) {
            return null;
        }

        int actualLengthFieldOffset = buffer.readerIndex() + lengthFieldOffset;
        long frameLength;
        switch (lengthFieldLength) {
        case 1:
            frameLength = buffer.getUnsignedByte(actualLengthFieldOffset);
            break;
        case 2:
            frameLength = buffer.getUnsignedShort(actualLengthFieldOffset);
            break;
        case 3:
            frameLength = buffer.getUnsignedMedium(actualLengthFieldOffset);
            break;
        case 4:
            frameLength = buffer.getUnsignedInt(actualLengthFieldOffset);
            break;
……

我们这里进入的是4，还记得在编码时候的开头的4位占位字节吗？跟踪进去发现。

public int getInt(int index) {
        return  (array[index]     & 0xff) << 24 |
                (array[index + 1] & 0xff) << 16 |
                (array[index + 2] & 0xff) <<  8 |
                (array[index + 3] & 0xff) <<  0;
    }

原来，当初在编码时，在流开头增加的4字节的字符是做这个的。他记录了当前了这个对象流的长度，便于在解码时候准确的计算出该对象流的长度，正确解码。看来，我们如果我们自己写的对象编码解码的工具，要考虑的还有很多啊。

附：LengthFieldBasedFrameDecoder的JavaDoc

/**
* A decoder that splits the received {@link ChannelBuffer}s dynamically by the
* value of the length field in the message.  It is particularly useful when you
* decode a binary message which has an integer header field that represents the
* length of the message body or the whole message.
* <p>
* {@link LengthFieldBasedFrameDecoder} has many configuration parameters so
* that it can decode any message with a length field, which is often seen in
* proprietary client-server protocols. Here are some example that will give
* you the basic idea on which option does what.
*
* <h3>2 bytes length field at offset 0, do not strip header</h3>
*
* The value of the length field in this example is <tt>12 (0x0C)</tt> which
* represents the length of "HELLO, WORLD".  By default, the decoder assumes
* that the length field represents the number of the bytes that follows the
* length field.  Therefore, it can be decoded with the simplistic parameter
* combination.
* <pre>
* <b>lengthFieldOffset</b>   = <b>0</b>
* <b>lengthFieldLength</b>   = <b>2</b>
* lengthAdjustment    = 0
* initialBytesToStrip = 0 (= do not strip header)
*
* BEFORE DECODE (14 bytes)         AFTER DECODE (14 bytes)
* +--------+----------------+      +--------+----------------+
* | Length | Actual Content |----->| Length | Actual Content |
* | 0x000C | "HELLO, WORLD" |      | 0x000C | "HELLO, WORLD" |
* +--------+----------------+      +--------+----------------+
* </pre>
*
* <h3>2 bytes length field at offset 0, strip header</h3>
*
* Because we can get the length of the content by calling
* {@link ChannelBuffer#readableBytes()}, you might want to strip the length
* field by specifying <tt>initialBytesToStrip</tt>.  In this example, we
* specified <tt>2</tt>, that is same with the length of the length field, to
* strip the first two bytes.
* <pre>
* lengthFieldOffset   = 0
* lengthFieldLength   = 2
* lengthAdjustment    = 0
* <b>initialBytesToStrip</b> = <b>2</b> (= the length of the Length field)
*
* BEFORE DECODE (14 bytes)         AFTER DECODE (12 bytes)
* +--------+----------------+      +----------------+
* | Length | Actual Content |----->| Actual Content |
* | 0x000C | "HELLO, WORLD" |      | "HELLO, WORLD" |
* +--------+----------------+      +----------------+
* </pre>
*
* <h3>2 bytes length field at offset 0, do not strip header, the length field
*     represents the length of the whole message</h3>
*
* In most cases, the length field represents the length of the message body
* only, as shown in the previous examples.  However, in some protocols, the
* length field represents the length of the whole message, including the
* message header.  In such a case, we specify a non-zero
* <tt>lengthAdjustment</tt>.  Because the length value in this example message
* is always greater than the body length by <tt>2</tt>, we specify <tt>-2</tt>
* as <tt>lengthAdjustment</tt> for compensation.
* <pre>
* lengthFieldOffset   =  0
* lengthFieldLength   =  2
* <b>lengthAdjustment</b>    = <b>-2</b> (= the length of the Length field)
* initialBytesToStrip =  0
*
* BEFORE DECODE (14 bytes)         AFTER DECODE (14 bytes)
* +--------+----------------+      +--------+----------------+
* | Length | Actual Content |----->| Length | Actual Content |
* | 0x000E | "HELLO, WORLD" |      | 0x000E | "HELLO, WORLD" |
* +--------+----------------+      +--------+----------------+
* </pre>
*
* <h3>3 bytes length field at the end of 5 bytes header, do not strip header</h3>
*
* The following message is a simple variation of the first example.  An extra
* header value is prepended to the message.  <tt>lengthAdjustment</tt> is zero
* again because the decoder always takes the length of the prepended data into
* account during frame length calculation.
* <pre>
* <b>lengthFieldOffset</b>   = <b>2</b> (= the length of Header 1)
* <b>lengthFieldLength</b>   = <b>3</b>
* lengthAdjustment    = 0
* initialBytesToStrip = 0
*
* BEFORE DECODE (17 bytes)                      AFTER DECODE (17 bytes)
* +----------+----------+----------------+      +----------+----------+----------------+
* | Header 1 |  Length  | Actual Content |----->| Header 1 |  Length  | Actual Content |
* |  0xCAFE  | 0x00000C | "HELLO, WORLD" |      |  0xCAFE  | 0x00000C | "HELLO, WORLD" |
* +----------+----------+----------------+      +----------+----------+----------------+
* </pre>
*
* <h3>3 bytes length field at the beginning of 5 bytes header, do not strip header</h3>
*
* This is an advanced example that shows the case where there is an extra
* header between the length field and the message body.  You have to specify a
* positive <tt>lengthAdjustment</tt> so that the decoder counts the extra
* header into the frame length calculation.
* <pre>
* lengthFieldOffset   = 0
* lengthFieldLength   = 3
* <b>lengthAdjustment</b>    = <b>2</b> (= the length of Header 1)
* initialBytesToStrip = 0
*
* BEFORE DECODE (17 bytes)                      AFTER DECODE (17 bytes)
* +----------+----------+----------------+      +----------+----------+----------------+
* |  Length  | Header 1 | Actual Content |----->|  Length  | Header 1 | Actual Content |
* | 0x00000C |  0xCAFE  | "HELLO, WORLD" |      | 0x00000C |  0xCAFE  | "HELLO, WORLD" |
* +----------+----------+----------------+      +----------+----------+----------------+
* </pre>
*
* <h3>2 bytes length field at offset 1 in the middle of 4 bytes header,
*     strip the first header field and the length field</h3>
*
* This is a combination of all the examples above.  There are the prepended
* header before the length field and the extra header after the length field.
* The prepended header affects the <tt>lengthFieldOffset</tt> and the extra
* header affects the <tt>lengthAdjustment</tt>.  We also specified a non-zero
* <tt>initialBytesToStrip</tt> to strip the length field and the prepended
* header from the frame.  If you don't want to strip the prepended header, you
* could specify <tt>0</tt> for <tt>initialBytesToSkip</tt>.
* <pre>
* lengthFieldOffset   = 1 (= the length of HDR1)
* lengthFieldLength   = 2
* <b>lengthAdjustment</b>    = <b>1</b> (= the length of HDR2)
* <b>initialBytesToStrip</b> = <b>3</b> (= the length of HDR1 + LEN)
*
* BEFORE DECODE (16 bytes)                       AFTER DECODE (13 bytes)
* +------+--------+------+----------------+      +------+----------------+
* | HDR1 | Length | HDR2 | Actual Content |----->| HDR2 | Actual Content |
* | 0xCA | 0x000C | 0xFE | "HELLO, WORLD" |      | 0xFE | "HELLO, WORLD" |
* +------+--------+------+----------------+      +------+----------------+
* </pre>
*
* <h3>2 bytes length field at offset 1 in the middle of 4 bytes header,
*     strip the first header field and the length field, the length field
*     represents the length of the whole message</h3>
*
* Let's give another twist to the previous example.  The only difference from
* the previous example is that the length field represents the length of the
* whole message instead of the message body, just like the third example.
* We have to count the length of HDR1 and Length into <tt>lengthAdjustment</tt>.
* Please note that we don't need to take the length of HDR2 into account
* because the length field already includes the whole header length.
* <pre>
* lengthFieldOffset   =  1
* lengthFieldLength   =  2
* <b>lengthAdjustment</b>    = <b>-3</b> (= the length of HDR1 + LEN, negative)
* <b>initialBytesToStrip</b> = <b> 3</b>
*
* BEFORE DECODE (16 bytes)                       AFTER DECODE (13 bytes)
* +------+--------+------+----------------+      +------+----------------+
* | HDR1 | Length | HDR2 | Actual Content |----->| HDR2 | Actual Content |
* | 0xCA | 0x0010 | 0xFE | "HELLO, WORLD" |      | 0xFE | "HELLO, WORLD" |
* +------+--------+------+----------------+      +------+----------------+
* </pre>
*
* @see LengthFieldPrepender
*/

阅读全文 »

发表于 | 阅读次数

还是梳理代码，频频到Future这个字眼，很自然的让我想到了未来。

还是那对男孩和女孩，女孩问男孩，你会娶我吗？男孩说，一定会，等我为你盖好一栋美丽的房子……

/**
 * Java小故事 我许你一个未来 Future
 * <p>
 * 还是那对男孩和女孩，女孩问男孩，你会娶我吗？<br>
 * 男孩说，一定会，等我为你盖好一栋美丽的房子……
 * 
 * @author lihzh
 * @alia OneCoder
 * @Blog http://www.coderli.com
 * @date 2012-7-26 下午8:44:58
 */
public class PromiseUAFuture {

	/**
	 * @author lihzh
	 * @throws ExecutionException
	 * @throws InterruptedException
	 * @alia OneCoder
	 * @date 2012-7-26 下午8:44:58
	 */
	public static void main(String[] args) throws InterruptedException, ExecutionException {
		// 我许你一个未来
		Future<BeautifulHouse> future = Executors.newSingleThreadExecutor().submit(new Boy());
		while (!future.isDone()) {
			System.out.println("Sorry baby, the house is not ok.");
		}
		System.out.println(future.get());
	}

	public static class Boy implements Callable<BeautifulHouse> {
		@Override
		public BeautifulHouse call() throws Exception {
			Thread.sleep(5000);
			return new BeautifulHouse();
		}

	}

	public static class BeautifulHouse {
		@Override
		public String toString() {
			return "This is a beautiful house.";
		}
	}
}
阅读全文 »

发表于 | 阅读次数

今天在梳理项目里一些老的代码逻辑和结构的时候，发现了一段观察者的代码。脑海里同时浮现出这样一个故事……

有一个女孩和一个男孩，他们在山里迷路了。晚上，他们都精疲力尽。男孩对女孩说，你睡会吧，我看着，有动静我叫你，然而……

/**
 * Java小故事，不舍得叫醒女孩的男孩
 * <p>
 * 有一个女孩和一个男孩，他们在山里迷路了。<br>
 * 晚上，他们都精疲力尽。男孩对女孩说，你睡会吧，我看着，有动静我叫你。<br>
 * 然而……
 * 
 * @author lihzh
 * @alia OneCoder
 * @blog http://www.coderli.com
 */
public class ObserverBoyAndGirlMain {

	/**
	 * @author lihzh
	 * @alia OneCoder
	 */
	public static void main(String[] args) {
		Boy boy = new Boy();
		Girl girl = new Girl();
		// 让女孩监听男孩的消息
		boy.addObserver(girl);
		try {
			// 然而，八个小时过去了，男孩的腿虽然已经被压得麻木了。
			Thread.sleep(8 * 60 * 60 * 1000L);
			// 但是，你舍得叫醒她么？：）
			// boy.wakeupGirl();
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
	}

	/**
	 * 男孩，观察周围的动静，有问题发出信号
	 * 
	 * @author lihzh
	 * @alia OneCoder
	 */
	public static class Boy extends Observable {
		/**
		 * 叫醒女孩
		 * 
		 * @author lihzh
		 * @alia OneCoder
		 */
		public void wakeupGirl() {
			setChanged();
			notifyObservers("");
		}
	}

	/**
	 * 女孩，睡着了，如果男孩叫她，则会醒来
	 * 
	 * @author lihzh
	 * @alia OneCoder
	 */
	public static class Girl implements Observer {
		@Override
		public void update(Observable o, Object arg) {
			System.out.println("Thank you, I'm up.");
		}
	}
}
阅读全文 »

发表于 | 阅读次数

看到题目，有的同学可能会想，上回不是说过对象传递了吗？是的，只是在《Java NIO框架Netty教程(八)-Object对象传递》中，我们只是介绍如何使用Netty提供的编/解码工具，完成对象的序列化。这节是想告诉你Netty具体是怎么做的，也许有的同学想自己完成序列化呢？况且，对象的序列化，随处可用：） 先看怎么编码。

@Override
    protected Object encode(ChannelHandlerContext ctx, Channel channel, Object msg) throws Exception {
        ChannelBufferOutputStream bout =
            new ChannelBufferOutputStream(dynamicBuffer(
                    estimatedLength, ctx.getChannel().getConfig().getBufferFactory()));
        bout.write(LENGTH_PLACEHOLDER);
        ObjectOutputStream oout = new CompactObjectOutputStream(bout);
        oout.writeObject(msg);
        oout.flush();
        oout.close();

        ChannelBuffer encoded = bout.buffer();
        encoded.setInt(0, encoded.writerIndex() - 4);
        return encoded;
    }

其实你早已经应该想到了，在Java中对对象的序列化自然跑不出ObjectOutputStream了。Netty这里只是又做了一层包装，在流的开头增加了一个4字节的标志位。所以，Netty声明，该编码和解码的类必须配套使用，与单纯的ObjectIntputStream不兼容。

		* An encoder which serializes a Java object into a {@link ChannelBuffer}.<br />
		* <p><br />
		* Please note that the serialized form this encoder produces is not<br />
		* compatible with the standard {@link ObjectInputStream}.&nbsp; Please use<br />
		* {@link ObjectDecoder} or {@link ObjectDecoderInputStream} to ensure the<br />
		* interoperability with this encoder.</p>

那么解码，自然是先解析出多余的4位，然后再通过ObjectInputStream解析。

关于Java对象序列化的细节问题，不在文本讨论的范围内，不过不知您是否感兴趣试试自己写一个呢？所谓，多动手嘛。

/**
 * Object编码类
 * 
 * @author lihzh
 * @alia OneCoder
 * @blog http://www.coderli.com
 */
public class MyObjEncoder implements ChannelDownstreamHandler {

	@Override
	public void handleDownstream(ChannelHandlerContext ctx, ChannelEvent e)
			throws Exception {
		// 处理收发信息的情形
		if (e instanceof MessageEvent) {
			MessageEvent mEvent = (MessageEvent) e;
			Object obj = mEvent.getMessage();
			if (!(obj instanceof Command)) {
				ctx.sendDownstream(e);
				return;
			}
			ByteArrayOutputStream out = new ByteArrayOutputStream();
			ObjectOutputStream oos = new ObjectOutputStream(out);
			oos.writeObject(obj);
			oos.flush();
			oos.close();
			ChannelBuffer buffer = ChannelBuffers.dynamicBuffer();
			buffer.writeBytes(out.toByteArray());
			e.getChannel().write(buffer);
		} else {
			// 其他事件，自动流转。比如，bind，connected
			ctx.sendDownstream(e);
		}
	}
}

/**
 * Object解码类
 * 
 * @author lihzh
 * @alia OneCoder
 * @blog http://www.coderli.com
 */
public class MyObjDecoder implements ChannelUpstreamHandler {

	@Override
	public void handleUpstream(ChannelHandlerContext ctx, ChannelEvent e)
			throws Exception {
		if (e instanceof MessageEvent) {
			MessageEvent mEvent = (MessageEvent) e;
			if (!(mEvent.getMessage() instanceof ChannelBuffer)) {
				ctx.sendUpstream(mEvent);
				return;
			}
			ChannelBuffer buffer = (ChannelBuffer) mEvent.getMessage();
			ByteArrayInputStream input = new ByteArrayInputStream(buffer.array());
			ObjectInputStream ois = new ObjectInputStream(input);
			Object obj = ois.readObject();
			Channels.fireMessageReceived(e.getChannel(), obj);
		}
	}
}

怎么样，是不是也好用？所谓，模仿，学以致用。

不过，提醒一下大家，这个实现里有很多硬编码的东西，切勿模仿，只是为了展示Object，编解码的处理方式和在Netty中的应用而已。

阅读全文 »

发表于 | 阅读次数

这是一个在比较特殊情况下才会发生的问题。不过却在笔者的身上发生了，既然如此，那就记录一下，也许还有其他朋友也会碰到。

问题描述：笔者办公环境使用Proxifile全局代码上网，不过对于一些不想走代理的程序和地址进行了过滤。然后笔者发现，Eclipse更新不好用了。查看Proxifile记录，发现Eclipse访问网址，都是通过ipv6协议。而ipv6似乎proxifile无法解析。于是，笔者在Eclipse的配置文件,eclipse.ini中加入下面一行配置。

-vmargs
-Djava.net.preferIPv4Stack=true

重启，生效。

然而，问题还没完。笔者最近一直在研究Netty。在启动Netty服务的时候，发现开始报无法绑定地址的错误。很显然，这也是由于设置proxifile代理产生的。（因为之前没有这个问题。），查看日志，还是ipv6的问题。这回是javaw.exe，走的ipv6协议。 一样的解决办法，临时在启动项参数中加入：

-Djava.net.preferIPv4Stack=true

问题解决，不过后来笔者有考虑了一下，这样一个一个设置太麻烦了，不如来个全局的，于是笔者在使用的jre上，设置了全局参数。一劳永逸了。：）

阅读全文 »