飞信Client和MapleFetion项目的登录模块浅析

题记:

      反正闲着还是闲着。以下分析基于MapleFetion2.5版本。

     

    以前在DD的时候,XX做了一个告警短信系统,后来问了下孙总,他说只是XX提供了接口,应用这边给个文件就好了。所以此路XXX了。

 

    最早研究起Fetion的大哥应该是邓东东,记得之前面试我还提到过他的名字,他的LibFetion也是自己做黑盒分析做出来的,算是第三方最好的了,也做了很久,用c写的,见http://www.libfetion.org 原是本着美好的愿望,希望大家在此基础上开发更好的应用,无奈由于非技术原因,不提供对外的so库,特别是windows版本的,你懂的....

    虽然不对外提供so库,但却出了各个平台的飞信app应用了。国家要有个无私奉献奖就好了。

   

    听说飞信是MSN那帮人做的,而且做法有很多相似的地方。在2007年的时候nathan大哥也对其研究了一番,见他博客http://hi.baidu.com/nathan2007/home,他的博客要是被那帮开发人员看见了,估计会喷血。我想nathan的博客对后来研究飞信的人提供了很大的帮助。其中一个就是MapleFetion项目了,作者solosky也是做了一番苦心的研究,最终开发了一个功能较全的三方lib,并且开源出来了,我觉得这对飞信本身的发展是利大于弊的。

 

    根据nathan大哥的黑盒分析,了解到fetion用到非标准的SIP协议+HTTP协议,在SIP上做了一点改动,感觉是被阉了,并改名叫SIPC。

    飞信的登录模块有2次验证:

    1、SSI验证

    通过HTTPS的GET方式通讯,URL为:https://uid.fetion.com.cn/ssiportal/SSIAppSignInV2.aspx?mobileno=159********&domains=fetion.com.cn%3bm161.com.cn%3bwww.ikuwa.cn&digest=89405402A0FC1A2FC73681229FB134E9638C4D5986C65BC9

 

digest后面那段是密码。

 

得到SIP:123456@fetion.com.cn;p=6721,结果码,和一个Credential

类似如下:

 

  <?xml version="1.0" encoding="utf-8" ?> 
- <results status-code="200">
- <user uri="sip:123456@fetion.com.cn;p=6721" mobile-no="159********" user-status="101" user-id="1233333">
- <credentials>
  <credential domain="fetion.com.cn" c="CBIOAADZDl2PfBl6ezl2Ljt9sWajwx2thKDwACt0dGTJ8gfb4C71CTLB7d8pxAD0BduMh7rO77pdWHIhHP2m0c7TRxQecfzOUCEfTyL09KaRQblUICPlBl/Whtp1M6WipxsyfX4AAA==" /> 
  <credential domain="m161.com.cn" c="CBAOAAAOPH9ouHxCxcsfS+XMPuAA8zN4nCaWV4t7mnHM6pkp6VHs1enfBCx/VT5lZ5lXU0WITAfctJ1f8wA4uUfyc1REihCQV/goRNumQC3VQinD1A==" /> 
  <credential domain="www.ikuwa.cn" c="ChAOAACTP8rQqlM7Sr3DbtWpRZv8HNrJpadWYWG0XWt3oNPWdSjx135Fk39Ghje1w4rdwZJ7eYtWX7/vv9lqD0uQzoio8CVuapOKZ1QcGa4fNJKaXQ==" /> 
  </credentials>
  </user>
  </results>

 

登录代码为:LoginState state = client.syncLogin();

登录主要类为:LoginWork.java

 

 LoginWork的工作包括了2次身份验证。完成了上一步,就开始SIPC的交互过程了,另外你可以不走SSI验证过程,但是你就必须得知道你的Fetion号,而非手机号。

 

SSI身份验证是类SSISignV2.java实现的,主要工作就是生成URL,发送HTTPS请求,接收HTTPS返回的结果,并解析,代码很简单,就不贴了。

SIPC验证是ServerDialog.java实现的,他主要工作是与飞信服务器进行通讯,其中包括消息的构造和发送。

 

在FetionClient初始化时会建立几个工厂:

 

public FetionClient(String account,
      String password,
      NotifyEventListener notifyEventListener)
 {
  this(new User(account, password, "fetion.com.cn"),
    notifyEventListener,
    new AutoTransferFactory(),
    new SimpleFetionStore(),
    new ThreadTimer(),
    new SingleExecutor());
 }

 

关于登录的运行有点怪怪的,作者用一个 new SingleExecutor()(实际上是一个1.5的单线程池:Executors.newSingleThreadExecutor();)来执行LoginWork。

 

 

2、开始SIPC验证

     前面分析到,与服务器的SIPC通讯主要是ServerDialog实现的,而他由DialogFactory工厂模式创建。

     和其他协议消息一样,消息分为头+消息体,由MessageFactory消息工厂创建,然后通过TCP,HTTP,MINA等底层通讯平台发送,消息被封装为SipcRequest.java,SipcResponse.java和SipcReceipt.java里。

 

    MessageFactory.java的主要作用就是构造一个个消息,消息构造就不贴代码了,很多硬编码了。 

 

    构造好消息后,传给上层ServerDialog.java,并由ServerDialog通过发送模块发送出去,并注册监听器。这个看得有点头昏,需要关注下,代码如下:

 

  /**
	 * 注册服务器
	 * @param presence		登录状态
	 * @param listener
	 */
	public void register(int presence, ActionEventListener listener)
	{
		SipcRequest request = this.getMessageFactory().createServerRegisterRequest(presence, 
					this.context.getTransferFactory().isMutiConnectionSupported());
		request.setResponseHandler(new ServerRegisterResponseHandler(context, this, listener));
		this.process(request);// 发送消息
		
	}

   

  /**
     * 发送数据包
     */
    @Override
    public void process(SipcOutMessage out)
    {
    	try {
	        this.processorChain.getFirst().processOutcoming(out);
        } catch (FetionException e) {
        	this.handleException(e);
        	//如果是传输异常,就将其抛出,让调用者处理传输错误
        	if(out instanceof SipcRequest) {
        		SipcRequest request = (SipcRequest) out;
        		if(request.getResponseHandler()!=null)
        			request.getResponseHandler().ioerror(request);
        	}
        }
    }

 

     看到发送消息通过process(request);从这个process看不出什么名堂。但是注意到在ServerDialog初始化的时候,初始化了这些process,如下:

 

 

    public void buildProcessorChain() throws FetionException
    {
		this.processorChain = new ProcessorChain();
		this.processorChain.addLast(new ServerMessageDispatcher(context, this, this));						//消息分发服务
		if(FetionConfig.getBoolean("log.sipc.enable"))
			this.processorChain.addLast(new SipcLogger("ServerDialog-"+this.context.getFetionUser().getFetionId()));									//日志记录
		this.processorChain.addLast(new TransferService(this.context));															//传输服务
		this.processorChain.addLast(new SipcParser());															//信令解析器
		this.processorChain.addLast(this.context.getTransferFactory().createDefaultTransfer());				//信令传输对象
		
		this.processorChain.startProcessorChain();
		
    }

其中 this.processorChain.addLast(new TransferService(this.context));建立一个传输processor放入processorChain这个以processor为节点的双链表。

 

我不太明白作者这样做的理由,看上去比较乱,processorChain里面什么都有,只能继续分析看看。

 

重新看了下各类Processor的处理逻辑后发现,原来作者的这个processorChain相当于一个过滤器,一个最原始的Request需要经过processorChain中每一个processor的处理,比如第一个是ServerMessageDispatcher模块,处理完后把Request对象传递给SipcLogger模块,从前往后,这样一层一层处理,最后由发送模块,也就是TCPTransfer的sendBytes进行发送。如下:

 

处理流程为:ServerMessageDispatcher-->SipcLogger-->TransferService-->SipcParser-->createDefaultTransfer-->网络-->飞信服务器

 

 protected void sendBytes(byte[] buff, int offset, int len)
            throws TransferException
    {
    	try {
	        this.writer.write(buff, offset, len);
	        this.writer.flush();
        } catch (IOException e) {
	       throw new TransferException(e);
        }
    	
    }

 

 这种把处理模块做成双链表的设计模式感觉还是有利有弊:),还是等待大大点评下吧。 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值