Java发送ios推送消息(APN)的代码示例

实际项目应用中,应该考虑使用开源项目java-apns:https://github.com/notnoop/java-apns
千万不要用一个叫JAVAPNS的项目。这个开源项目的代码非常烂,每次发送消息都重新建立socket连接。在apple的文档中,都明确的说了会把这种行为当作dos攻击行为。性能差就更不用说了。
ios手机上要安装对应的应用。该应用与.p12证书文件应该匹配。
apple官方的,关于APN服务,和apn的feedback的文档在这个地方:https://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/CommunicatingWIthAPS.html#//apple_ref/doc/uid/TP40008194-CH101-SW3
java版本发送apn推送代码示例:
继续阅读“Java发送ios推送消息(APN)的代码示例”

使用httpclient 4.1访问自签名证书的https url

之前发现有些同学写的httpclient的代码不规范,于是参考官方文档整理了之前的一篇博客多线程情况下HttpClient的使用。今天发现我们的一个https的url,是自签名证书的,并非到认证服务器去认证。 在之前的HttpClient写法下,请求这个url会报告这样的异常:
继续阅读“使用httpclient 4.1访问自签名证书的https url”

网络基础知识备忘

再一次翻开这本经典的《TCP/IP详解》,发现许多东西都忘记了。重新看的过程中摘下一些知识点作为笔记,记录在这里。

四层模型:

链路层,网络层,运输层,应用层。

TCP传给IP的数据单元称作TCP报文段(TCP segment),IP传给网络接口层的数据单元称作IP数据报(IP datagram),通过以太网传输的比特流称作帧(Frame)。

以太网帧的特性是,长度必须在46-1500字节之间。TCP帧的组成如下:

以太网首部(14字节),IP首部(20字节),TCP首部(20字节),应用数据,以太网尾部(4字节)。

UDP数据与TCP数据基本一致,不同的是,UDP的首部长度为8。

我自己的理解,这里的“帧”的概念应该是逻辑上概念。即“在以太网传输的比特流”。而实际上在传输的时候,会经过一个“以太网封装”,在这46-1500字节的数据之前增加一个头部,包括6字节目标地址,6字节源地址等。还在尾部增加了4字节的CRC校验值。

继续阅读“网络基础知识备忘”

用ssh做socks5代理,并使进程后台驻留

因为工作需要,利用ssh做socks5代理进行翻墙,供自己和同事们使用。国外一个虚拟主机,国内一台测试机通过ssh连接上去。

在一台测试机上,执行命令如下:

ssh root@106.187.xx.xx -D 5000 -g -f ‘sleep 30d’

-D指定的是开5000端口。 -g参数加上后才允许其它主机通过本机端口转发请求。 -f是使进程fork到background。 至于为什么要sleep 30d呢,这是因为如果不加任何命令,会被提示“Cannot fork into background without a command to execute.”。

 

这样大家就可以在firefox的代理中设置socks5代理, ip指定测试机的ip,端口5000,就可以翻墙了。

继续阅读“用ssh做socks5代理,并使进程后台驻留”

KeepAlive简介

简单的说,keepalive就是保持连接不断开。 在我们的开发领域,有两个层面的keepalive:HTTP层面的和TCP层面的。

HTTP keepalive:
http层面的keepalive,也叫做connection reuse或persistent connection。 它指的是,在一个tcp连接上,收发多个http请求。而不是为每一次http请求/响应都建立新的TCP连接。
在HTTP 1.0协议中,没有明确的规范指明keepalive应该是怎样的。如果客户端支持keepalive,那么它在请求的header中会增加这样一个值:Connection: Keep-Alive。服务器在收到这个请求,并做出响应的时候,同样会在header中增加Connection: Keep-Alive。这样一来,这个连接就会被保持着而不被断开。当客户端要发起一个新的http请求时,将会重用这个连接。这个连接会一直保持着,直到客户端或服务器端主动断开。

在http1.1中,任何连接都被默认是持久(persistent)的,除非声明了不是。在Apache HTTP Server 2.0中,默认的timeout时间只有15s,而2.2版本则更短,为5s。较短的timeout时间的好处是,迅速传输一个web页面中的所有元素(css,图片等),而又不会因为需要更多的操作系统进程或线程而消耗系统资源。

继续阅读“KeepAlive简介”

android系统上修改hosts文件

首先需要root。android系统的root,可以参考之前的博文: http://www.thinkingquest.net/articles/33.html。

安装busybox。这样就有了vim等常用工具。

此时还不能修改hosts文件,即使用adb shell登陆到手机android系统,su命令切换到root用户后,仍然不能编辑/etc/hosts文件。 因为/system是mount为readonly的。可以这样查看结果:

root@android:/ # mount | grep system
/dev/block/platform/omap/omap_hsmmc.0/by-name/system /system ext4 ro,relatime,barrier=1,data=ordered 0 0

重新mount为rw模式,输入命令:

mount -o rw,remount /system

再次查看:

root@android:/ # mount | grep system
/dev/block/platform/omap/omap_hsmmc.0/by-name/system /system ext4 rw,relatime,barrier=1,data=ordered 0 0

已经是rw模式。这样就可以编辑/etc/hosts文件了。 对于android软件开发过程中的调试,时常会有意义。

 

2013年5月24日edit:

有的系统版本上,上述的mount命令会报告错误。 那么可能需要这么写:

mount -o remount /dev/block/mtdblock0 /system

其中的mtdblock0,不同的机型是不同的。可以先无参数的mount命令看一下,原本mount到/system的是哪个设备。

 

(全文完)

多线程情况下HttpClient的使用

3.x版本的httpclient属于apache的commons项目。 从4.x开始,httpclient被转移到了httpcomponent项目下。 api也发生了重大的变化。 http 3.x已经不推荐使用。使用3.x版本的地方,官方建议都升级到4.x版本。

本文的api也都基于4.x版本。下面是一个最simple的案例:

继续阅读“多线程情况下HttpClient的使用”

我的vim设置

首先在home目录下建立一个文件 .vimrc 。 vim的配置文件在/etc/vimrc,放在home目录下的 .vimrc只对自己用户有效。

set nu
默认显示行号。这个还是很有必要的。

colorscheme evening
设置一个配色方案这里选的是evening。 还有ron也不错。 可以看目录/usr/share/vim/vim73/colors下边有配色文件。 其中”vim73“是版本,随着不同版本应该不同。

继续阅读“我的vim设置”