一 背景 最近在园子了浏览了几篇有关Socket文章,得到了一些启发萌生了想要重构公司在2000年用.NET Framework 2.0 与 Visual Studio 2005开发的AsySocket项目为了希望能够尽快的了解公司这个项目,Google了很多国内外的网站让我对Socket有了更深层次的了解也知道Socket从2.0到4.0发生许多变化,比如在2.0中没有SocketAsyncEventArgs类,大家在园子里把这个类说的这么邪乎,小弟不才有想尝试着使用.NET Framewor…

一 概述 Socket服务只是提供一个网络传输服务. 业务逻辑层在整体架构中的位置在那里呢,如图: 网络层将解包后的消息包抛至业务逻辑层,业务逻辑层收到消息包后,解析消息类型,然后转入相应的处理流程处理 网络层应提供发送消息的接口供业务逻辑层调用,因为网络层不会主动发送消息,发送消息的操作是由业务逻辑层来控制的,所以业务逻辑层应根据具体的业务应用,封装不同功能的发送消息的方法. 二 设计 那我们有应该如果来设计业务逻辑层呢,尽量与Socket解耦合以达到相对的独立性. 根据上面的图来说是根据业务…

一 概述 Socket服务器性能要好就要经过无数次的测试,来保证,以下是记录一次的测试经过. 机器配置:Inter(R) Core(TM) i3-2310m CPU 2.10GHz RAM 6.00GB,64位系统 今天的测试主要是5个客服端连接和连续发送2000数据包,每个包大概在55192大小. 二 测试准备工作   在测试之前需要准备哪些呢. 启动多客服端.bat 代码如下: @echo off echo 请稍等...... for /l %%i in (1,2,12) do  start…

TYPESDK 服务端设计思路与架构之一:应用场景分析 作为一个渠道SDK统一接入框架,TYPESDK从一开始,所面对的需求场景就是多款游戏,通过一个统一的SDK服务端,能够同时接入几十个甚至几百个各种渠道的SDK.而且这些渠道接口的具体接入字段和接入逻辑,每个月以至每周,都可能发生或大或小的变动.在这样一个复杂的应用场景下,我们应该如何设计一个足够强大而又足够灵活的SDK服务端呢? 首先我们需要厘清,在整个应用场景中,TYPESDK所处的位置,以及它所需要实现的核心功能. 图1 如图1所示,T…

题记:很多做游戏开发的人,估计都或多或少地接过渠道SDK,什么UC,当乐,91,小米,360……据统计国内市场当前不下于100家渠道,还包括一些没有SDK的小渠道.每个渠道SDK接入的方法呢,多是大同小异.但是,正是这些小异,又让SDK的接入,产生了无穷无尽的变数.所以,接入SDK之前,如果你没有经验,或者没有被SDK坑过,那么当你看到这系列文章的时候,你很幸运,你可以避免这一切了.如果你之前被坑过,而且还在继续被坑着,那么现在,就是你解脱的时刻. 完成一个SDK的接入并没有多少技术含量,但是能…

题记:很多做游戏开发的人,估计都或多或少地接过渠道SDK,什么UC,当乐,91,小米,360......据统计国内市场当前不下于100家渠道,还包括一些没有SDK的小渠道.每个渠道SDK接入的方法呢,多是大同小异.但是,正是这些小异,又让SDK的接入,产生了无穷无尽的变数.所以,接入SDK之前,如果你没有经验,或者没有被SDK坑过,那么当你看到这系列文章的时候,你很幸运,你可以避免这一切了.如果你之前被坑过,而且还在继续被坑着,那么现在,就是你解脱的时刻. 完成一个SDK的接入并没有多少技术含量…

在前一篇文中,我们对一个聚合SDK服务端所需要实现的功能作了简单的分析.通过两个主要场景的功能流程图,我们可以看到,作为多款游戏要适配多个渠道的统一请求转发中心,TYPESDK服务端主要需要实现的功能有以下几个要点: l  接收请求和返回响应,通常是HTTP的请求响应. l  获取配置信息. n  识别游戏,根据请求中的信息,获取到具体游戏的相关配置. n  识别渠道,根据请求中的信息,获取针对具体渠道的配置. n  根据请求中的信息,获取特定游戏在渠道上的参数 l  处理请求逻辑,根据请求种类…

有了前文几个步骤的分析和设计,TYPESDK的信息交互流程已经可以正常工作了,但是,这个流程还没有考虑到支付这样的过程中,至关重要的信息安全问题. 在整个交互过程中,游戏服务端,SDK服务端,渠道服务端都属于安全区域,这部分发生的数据交互,基本是可以信任的,只需要作相对简单的处理工作:而客户端,包括游戏客户端,SDK客户端都属于危险区域,在这部分产生的数据和请求,都有可能受到外部的拦截和篡改.因此,我们需要在流程上加以预防和控制. 图1 从示意图1可以看出.针对三类不同安全性的数据流,我们的处理…

经过前两篇文字的分析与设计,我们已经可以搭建出一个能够支持多游戏多渠道的聚合SDK服务端,但这只是理想化状态下的一个简化模型.如果接入渠道的逻辑都是按照理想化的简化过程来构建,那么对于支付的请求,我们可以简化成这样几步: 游戏客户端创建订单. 游戏客户端(通过TYPESDK客户端)调用渠道lib库中相应接口,发起支付. 用户在弹出的支付窗口完成支付. TYPESDK服务端等待渠道服务端的回调,收到回调后通知游戏服务端. 游戏服务端执行发货动作. 但是显然这个简化流程在实际上线时是不够满足需求的,…

thrift框架总结,可伸缩的跨语言服务开发框架 前言: 目前流行的服务调用方式有很多种,例如基于 SOAP 消息格式的 Web Service,基于 JSON 消息格式的 RESTful 服务等.其中所用到的数据传输方式包括 XML,JSON 等,然而 XML 相对体积太大,传输效率低,JSON 体积较小,新颖,但还不够完善.本文将介绍由 Facebook 开发的远程服务调用框架 Apache Thrift,它采用接口描述语言定义并创建服务,支持可扩展的跨语言服务开发,所包含的代码生成引擎可以…