精华内容
下载资源
问答
  • USB CDC从理论到实践

    万次阅读 多人点赞 2017-08-07 11:56:23
    本文摘自ST官网的“USB CDC类入门培训”。整理的内容是我能够看得懂的,认为比较实用的,记录下来,...http://bbs.21ic.com/forum.php?mod=viewthread&tid=726814&page=1&extra=#pid42250641 USB CDC类基础理论知识介

    本文摘自ST官网的“USB CDC类入门培训”。整理的内容是我能够看得懂的,认为比较实用的,记录下来,以便以后查阅,同时也把原文档中的笔误给更正了一下。若要看更详细的可以去ST技术文档中查看,链接为:
    http://bbs.21ic.com/forum.php?mod=viewthread&tid=726814&page=1&extra=#pid4225064

    1 USB CDC类基础理论知识介绍

    1.1 USB CDC类、USB2.0标准与PSTN之间的关系

    CDC(Communication Device Class)类是USB2.0标准下的一个子类,定义了通信相关设备的抽象集合。它与USB2.0标准以及其下的子类的相互关系如下图所示:
    这里写图片描述
    如上图,USB2.0标准下定义了很多子类,有音频类,CDC类,HID,打印,大容量存储类,HUB,智能卡等等,这些在usb.org官网上有具体的定义,这里主要介绍通信类CDC。

    1.2 从一个具体的CDC类通信数据说起

    这里写图片描述
    如上图,USB CDC类的通信部分主要包含三部分:枚举过程、虚拟串口操作和数据通信。其中虚拟串口操作部分并不一定强制需要,因为若跳过这些虚拟串口的操作,实际上USB依然是可以通信的,这也就是为什么上图中,在操作虚拟串口之前会有两条数据通信的数据。之所以会有虚拟串口操作,主要是我们通常使用PC作为Host端,在PC端使用一个串口工具来与其进行通信,PC端的对应驱动将其虚拟成一个普通串口,这样一来,可以方便PC端软件通过操作串口的方式来与其进行通信,但实际上,Host端与Device端物理上是通过USB总线来进行通信的,与串口没有关系,这一虚拟化过程,起决定性作用的是对应驱动,包含如何将每一条具体的虚拟串口操作对应到实际上的USB操作。需要注意的是,Host端与Device端的USB通信速率并不受所谓的串口波特率影响,它就是标准的USB2.0全速(12Mbps)速度,实际速率取决于总线的实际使用率、驱动访问USB外设有效速率(两边)以及外部环境对通信本身造成的干扰率等因素组成。

    1.3 CDC类设备枚举过程

    CDC类设备与其他标准USB设备枚举过程的并没有什么特殊的地方。在设备描述符内可以使用DeviceClass=0x00, SubClass=0x00, Protocol=0x00 表示此类信息在接口描述符内给出;或者也可以使用0x02,0x00,0x00;来表明该设备为CDC类设备。或者使用0xef, 0x02,0x01表示当前为复合设备。
    CDC类设备在枚举过程中最主要的信息存储在配置描述符内:
    这里写图片描述
    如上图所示,CDC类的配置描述符一般包含两个接口:一个控制接口(Interface 0),另外一个是数据接口(Interface 1), 除此之外,还有一个虚线指向的IAD(Interface Association Description),表示这个是可选的,得根据实际情况来确定其是否真实存在。
    在ST给出的CDC例程中,主要是使用SetLineCoding指令来设置和修改虚拟串口的波特率,使用GetLineCoding来获取当前波特率,使用SetControlLineState来打开或关闭串口,这种操作是在Host端CDC驱动来具体映射实现的, Device端收到控制指令可以处理也可以不处理,用CubeMx自动生成的CDC类代码对接收到的任何控制指令到没有做任何处理,如果需要的话,用户可按应用的需要来处理。
    这里写图片描述

    2 CDC类软件框架介绍

    2.1 CDC软件框架简介

    这里写图片描述
    如上图所示,黄色USB Device Core部分为USB设备库文件,属于中间件,它为USB协议栈的核心源文件,一般不需要修改:

    USB Device Core中,Log/debug为打印/调试开关;
    core为USB设备核心;
    USB request中定义了枚举过程中各种标准请求的处理;
    I/O request为底层针对USB通信接口的封装。

    黄色USB Device Class部分为USB类文件,也属于中间件,USB设备库,目前ST DEMO中支持的类有HID, Customer HID, CDC, MSC, DFU, Audio, ST提供了这些类的源码框架,其他的Class或者是复合设备需要自己根据实际需求情况进行扩展或定制。如果用户需求只是需要一个标准类,比如CDC通信,那么最好就使用现成的代码,不需要做任何修改就可以实现这个CDC类通信的功能。
    蓝色USB Device HAL Driver为HAL库部分,是对USB外设接口的封装,属于底层驱动,不需要修改,它分为PCD和LL Driver,PCD处于LL Driver之上。
    洋红色USB Device Configuration为USB配置封装,位于USB底层HAL层驱动与中间件USB协议栈之间,一方面向上层(USB设备库)提供各种操作调用接口,另一方面,向底层USB驱动提供各种回调接口。正是由于它的存在,使得USB协议栈(USB设备库)与底层硬件完全分离,从而使USB设备库具有更加兼容所有STM32的通用性。USB Device Configuration为开放给用户的源文件,用户可以根据自己的某些特殊需要进行修改,也可以使用默认的源文件,假如没有任何特殊要求的话,我们使用默认即可。
    Application为应用层,USB Device Class有可能将自己对应该的操作接口封装在一个操作数据结构中,由应用来具体实现这些操作,在系统初始化时,由应用将已经定义好的操作接口注册到对应的USB类中,比如usbd_cdc_if, 就这样,使得应用层的应用代码与属于中间件层的USB协议栈分离。同时,USB协议栈会将一些字符串描述符放到APP中,当USB初始化时将这些已经定义好的字符串通过指针初始化到USB协议栈中,以便后续需要时获取。

    2.2 工程源码文件与软件框架的对应关系

    这里写图片描述

    2.3 USBD内核与USBD_CDC的关系

    2.1节中,提到过ST官方Cube库中提供的官方USB协议栈,主要是包含了USBD内核与USB各种类。USBD内核一般是固定的,用户一般不需要修改,但USBD类,如果用户需要修改或者扩展,比如复合设备或者用户自定义设备,还有就是,ST目前官方提供的USB设备类的DEMO程序并没有囊括所有USB类,因此,若用户需要实现这些官方提供DEMO之外的USB类时,则用户需要根据自己的需要来定制化自己的USB类。
    ST提供的USB协议栈中已经有USBD内核,且这个内核源文件一般是不需要修改的,我们需要自定义这么一个USB类,我们首先得知道要自定义的USB类是如何与USBD内核打交道的。
    USB协议栈将所有USB类都抽象成一个数据结构:USBD_ClassTypeDef,其定义如下所示:
    这里写图片描述
    这个结构体是一个抽象类,定义了一些虚拟函数,比如初始化,反初始化,类请求指令处理函数,端点0发送完成,端点0接收处理,数据发送完成,数据接收处理,SOF中断处理,同步传输发送未完成,同步传输接收未完成处理等等;用户在实现自己具体的USB类的时候需要将它实例化,USBD_ClassTypeDef结构体是USBD内核提供给外部定义一个USB设备类的窗口,而USB类文件(如usbd_cdc.c)实际就是实现这个结构体具体实例化的过程。最后将这个具体实例化的对象注册到USBD内核的同时, USBD内核与USBD类也进行了关联。
    这里写图片描述
    可以这么说,USBD内核与USBD类之间的纽带就是USBD_ClassType这个结构体
    下面我们来看看ST提供的CDC DEMO中具体CDC类:
    这里写图片描述
    这个就是具体一个CDC类实例化的对象,上层应用通过USBD_RegisterClass函数,将此对象注册到usbd内核 :
    这里写图片描述
    它主要在usbd_cdc.c源文件中实现它的各个成员函数,当然,usbd_cdc.c源文件中,除了这些CDC类成员函数的具体实现之外,还包含其他一些对上层提供的接口,比如发送USBD_CDC_TransmitPacket, USBD_CDC_RegisterInterface,上层应用通过调用USBD_CDC_TransmitPacket来发送数据,通过USBD_CDC_RegisterInterface来注册操作接口,这也是我们接下来将要讲述的内容。

    2.4 USBD_CDC与USBD_CDC_If的关系

    讲完了USBD内核与USBD_CDC的关系,接下来讲USBD_CDC与上层应用是如何对接的。为了将USBD_CDC与上层应用层完全分离出来,类似USBD内核与USBD_CDC类完全分离一般,USBD_CDC类对上层同样提供一个抽象的数据操作接口USBD_CDC_If结构体:
    这里写图片描述
    如上所示,如何处理来自Host端发送过来的控制指令和数据,完全是由应用层来决定,具体实现是应用层将此抽象的操作接口具体实例化,并注册到USBD_CDC类对象中:
    这里写图片描述
    如上图所示,通过引入USBD_CDC_If这么一个数据结构,就实现了USBD_CDC类与应用层的完全分离。USBD_CDC_If的具体实例化对象如下:
    这里写图片描述
    源文件usbd_cdc_if.c就是实现这些成员函数的过程,除此之外,还包含发送接口。最后应用层通过调用USBD_CDC_RegisterInterface函数将此操作接口注册到USBD_CDC类中 :
    这里写图片描述

    2.5 应用接口

    初始化 :
    这里写图片描述
    如上图所示 :
    初始化分4步:
    1> 初始化USBD内核
    2> 给USBD内核注册USBD_CDC类
    3> 给USBD_CDC类注册USBD_CDC_If接口
    4> 正式启动USBD

    • 发送数据:
      uint8_t CDC_Transmit_FS(uint8_t* Buf, uint16_t Len);
    • 接收回调处理:
      static int8_t CDC_Receive_FS (uint8_t* Buf, uint32_t *Len);
    • 接收控制指令处理 :
      static int8_t CDC_Control_FS (uint8_t cmd, uint8_t* pbuf, uint16_t length);

    3 实践动手部分

    3.1 实验环境及STM32F072-Discovery板简介

    硬件准备:

    • STM32F072 Discovery板一块
    • Mini USB线两根
    • PC一台

    软件准备:

    • IAR V6.7.0 或者以上版本
    • STM32CubeF0 V1.7.0
    • STM32CubeMX V4.19
    • SSCOM串口工具
    • VCP虚拟串口驱动
      这里写图片描述
      这里写图片描述

    3.2 使用STM32CubeMx制作CDC工程

    这里写图片描述
    这里写图片描述

    使用内部48M的HSI48 RC作为时钟源
    这里写图片描述
    这里写图片描述
    这里写图片描述
    最终生成的代码工程与USB CDC类软件框架的对应关系:
    这里写图片描述

    3.3 添加测试代码

    为了更好的验证通信,我们需要添加点测试代码:
    这里写图片描述
    在接收回调中,我们将接收到的数据转给HandleReceiveData函数处理:
    这里写图片描述
    而在HandleReceiveData函数中我们将收到的数据原样返回给Host端,这样一来,Host端的串口工具将发送什么就将收到什么。
    这里写图片描述
    另一方面,我们定义了一全局变量StartFlag,它用来标志是否循环从Device端向Host端主动发送数据,其值由外部按键控制。然后在Main函数内的while(1)循环内添加如下测试代码:
    这里写图片描述
    只要StartFlag标志为1,在枚举结束后则不断向Host端发送数据。

    3.4 验证结果

    在编译完并将代码烧录进MCU后,我们首先验证PC端通过串口工具发送数据的情况:
    这里写图片描述
    如上图所示,串口工具发送63个字节到Device端后,能够接收到从Device端返回到的一模一样的数据,这说明发送与接收都是正常的。
    这里写图片描述

    在按下用户按键后,串口工具能够无限收到来自Device端的数据。
    这里写图片描述
    收发同时进行也是正常的。至此,USB CDC设备端的收发验证均正常。

    3.5 注意事项

    展开全文
  • 从理论到实践落地「微服务

    千次阅读 2017-10-10 09:35:45
    从理论到实践落地「微服务」 作者|程超编辑|小智若论近年来大热的技术名词,微服务必定有一席之地。对于微服务的阐述已有很多,但很多不过流于框架、架构介绍,恍若空中楼阁。这是一篇理论实践结合谈微服务的...

    从理论到实践落地「微服务」(附80页PPT下载)

    作者|程超

    若论近年来大热的技术名词,微服务必定有一席之地。对于微服务的阐述已有很多,但很多不过流于框架、架构介绍,恍若空中楼阁。这是一篇理论与实践结合谈微服务的文章,回复关键词「微服务」,下载作者80页PPT的呕心之作。如果你想更深入学习微服务,请看今日次条推送。

    写在前面

    一直对微服务非常感兴趣,因为公司的架构改造正好有机会能够接触微服务,买来一些书,请教了很多微服务大牛同时自己也做了很多总结,写成了80页ppt,算是我对微服务的一个认识吧,微服务本身不同的人有不同的理解,而我就从我自己的角度来谈谈微服务是什么。

    目前市面上的不少书或者不少相关文章写的都是框架的使用,或者架构的介绍,其实对于刚入门不久的同学来说很容易造成微服务就是一堆框架和组件的堆砌,于是今天我将从理论和实践的角度来说说微服务。

    现代互联网的方向是当企业发展到一定规模后,一定是大规模、云计算和大数据的三者的结合,从而形成平台,那么微服务就是基于此而提出的。

    一、什么是微服务

    1、常见的系统架构

    目前我们经常接触的网络架构主要有三种,如下图:

    从图中可以看到,共有三种模式,第一种是集中式架构也是单块应用最常使用的架构模式。第二种是分布式架构,最常见的应用是将一个大的任务拆分到不同的机器中进行计算,最终有一台服务器合并计算结果就是分布式架构的一个好的体现。第三种就是微服务架构。

    2、现实遇到的挑战

    扩容困难

    我们之前开发项目用的是虚拟机,每次上线项目需要加机器总会遇到资源不足的情况,还要走非常复杂工单审批流程,还要与运维人员不断PK,才能申请下来资源,整个流程冗长,机器受限于资源申请困难。

    部署困难

    每次上线采用专门的人进行布署,上线之前需要与上线人员沟通上线的环境,防止上线出错。

    发布回滚困难

    每次上线发现问题后,需要重新从svn主干上面进行代码编译,但是有时候会因为各种问题回滚失败,而且重新编译很耗时导致回滚缓慢。

    适配新技术困难

    如果打算在不同的模块采用不同的语言开发,或者想在架构中做技术升级都很困难或者不支持。

    快速开发困难

    项目中采用单体应用,里面集成了太多功能模块,无法快速进行功能开发并且很容易牵一发动全身。

    测试困难

    测试人员没有自动化测试框架,或者Mock系统,导致只能采用简单的人工测试流程,而且还经常发生功能覆盖不全面等问题。

    学习困难

    于是我们把项目中遇到上述问题的项目称为单体应用。

    3、微服务的定义

    The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services , which may be written in different programming languages and use different data storage technologies.

    – James Lewis and Martin Fowler

    原文:

    翻译文:

    总结了一下共有四点特性:

    • 一些列的独立的服务共同组成系统

    • 单独部署,跑在自己的进程里

    • 每个服务为独立的业务开发

    • 分布式的管理

    4、微服务和SOA的区别

    • 微服务只是一种为经过良好架构设计的SOA解决方案,是面向服务的交付方案。

    • 微服务更趋向于以自治的方式产生价值。

    • 微服务与敏捷开发的思想高度结合在一起,服务的定义更加清晰,同时减少了企业ESB开发的复杂性。

    • 微服务是soa思想的一种提炼!

    • SOA是重ESB,微服务是轻网关。

    5、微服务定义小结

    二、关于微服务的建模

    我们在谈建模,首先想到的是领域驱动设计的内容,没错,微服务的建模思想也是基于建模的思想,下面我将给简单给与介绍什么样的服务才算是好服务。

    1、松耦合和高内聚

    • 松耦合:修改一个服务不需要同时修改另一个,每个微服务都可以单独修改和布署。

    • 高内聚:把相关的事务放在一起,把不相关的排除出去,聚集在一起的事务只能干同一件事。

    用如下图可以清晰的表示:

    2、限界上下文

    • 限界:就是划分、规定,界限、边界。

    • 上下文:是业务的整个流程。

    当我们检查已有的系统时,经常会发现系统中存在混杂在一起的模型,他们之间的边界是非常模糊的。此时你应该为整个系统绘制一个边界,然后将其归纳在大泥球范围之内。往往在我们所在的项目中,经常是项目版本的迭代的时候出现这样的情况,导致后期维护代码越来越困难。

    3、逐步上下文

    划分方法:一开始识别粗粒度的限界上下文、这些粗粒度的上下文可能包括一些套嵌的限界上下文,这些套嵌的上下文不直接对外可见。

    暴露原则:使用粗粒度上下文还是套嵌上下文暴露服务,哪个更合理,应该有组织结构来决定的。

    正如上面二个图的示例所示,图一的订单处理,货物接收和库存管理三个模块在项目研发初期被归集到了仓库服务中,财务服务获取库存管理的数据,直接访问仓库服务的库存管理接口就可以了。随着这三个模块的不断演进和壮大,单个服务已经不能满足业务和团队发展的需求,这时候将这三个模块分别拆分演变成图二的结构图,这时候订单管理,货物接收和库存管理分别以服务的形式对应不同的团队,财务服务只需请求库存管理服务就可以得到相应的数据。

    三、关于微服务的集成

    1、集成原则

    微服务的集成做到好,可以保持自治性、可以独立发布修改和发布。

    • 避免破坏性修改 服务的一些修改不能导致该服务的消费方发生改变。

    • 保证API与技术的无关性

    • 保证API的易用性

    • 隐藏内部实现细节

    2、编排与协同

    编排:同步调用一组服务,等待各个服务的返回结果。优点知道业务流程中每一步跨服务调用结果,缺点容易承担太多的调用,太耗时,导致调用方的不稳定性。

    协同:异步调用一组服务或服务调用加入队列中,降低服务之间的耦合度,带来的额外工作业务流程跨服务的监控,不过可通过消费方处理完成后,回调服务方告知处理结果。

    编排

    协同

    3、版本管理

    • 尽可能推迟破坏性修改 宽进严出的原则

    • 尽早发现破坏性的修改 按照契约,通过测试及早发现是服务方还是消费方破坏性的修改

    • 不同的接口版本共存 最好共存两个版本

    4、案例分析

    案例一:如何拆分单块系统结构

    当我们看到一个单块系统时,往往首先要从数据库入手进行拆分,规划好哪些是财务代码的表,哪些是客户代码的表,将二者进行分离,这时候单块系统的应用结构并没有拆分,这还需要我们在进行设计单块系统的时候,客户代表和财务代码的表字段不能混在一起,还是要设计成不同的表才能方便我们将来拆分,虽然系统是在一起的,但是却为未来做了拆分准备,最后将应用系统拆分独立布署,这个过程就结束了。

    案例二:如何跨系统访问数据表

    有二个服务,分别是产品目录和财务,左图的场景是财务服务直接调用产品目录的数据表进行数据获取,这种跨服务的数据获取方式是有问题的,首先我们无法把控财务服务是如何获取数据的,是否对我们的数据表造成影响,其次从设计的角度来说无疑又增长了系统之间调用的耦合度,系统之间的依赖又增强了。于是演变成右图这样,左图只需提供服务接口给右图调用即可。

    案例三:服务设计中的坏味道

    在这样的系统中,ABCD四个系统进行了串联,这样也就要求这四个系统分别都是高可用,如果其中任何一个系统挂了或者发生问题,都会直接影响其他所有系统,所以我们设计微服务架构的时候要尽量避免这种集中式的架构。

    四、如何大规模的使用微服务

    我们真正使用微服务的时候,有很多需要注意和关注的点:

    1、故障无所不在

    网络是不可靠,只能尽力限制引起故障的因数,达到一定规模后,故障不可避免。

    2、跨功能需求

    服务吞吐量、可用性和数据持久性等这些需求需要持续测量,并保证服务满足可接受的目标。

    3、功能降级

    构建弹性系统,因微服务功能分散,在有可能down机的微服务上,能够安全的降级以保证弹性

    4、反服务脆弱

    为了不会引起严重级联影响,需要正确的设置超时、实现舱壁隔离或断路层等以避免在第一时间调用一个不健康的服务。

    超时

    设置超时时间对于调用下游服务十分重要,超时时间设置太长有可能把下游系统拖慢,设置太短可能下游服务未处理完成。最好设置一个默认的超时时间,当超时发生时后,记录到日志里看看发生了什么,并且做响应的调整。

    断路器

    使用断路器,当请求下游服务发生一定数量的失败后,短路器打开,接下来的请求快速失败。一断时间后,查看下游服务是否已服务,重置断路器。

    舱壁

    为每个下游服务建立单独的连接池。超时和断路器资源受限时释放资源,舱壁第一时间确保它不成为限制。还有一个拒绝请求的舱壁,用以避免资源饱和,称之为减载。

    隔离

    当下游服务离线,上游服务不受影响。设置成为服务间隔离。

    5、幂等

    幂等操作,多次执行所产生的影响,均与一次执行影响相同。可以把某些特定业务操作设计成幂等的,比如客户下单送积分。

    6、扩展

    增加负载、减少延迟。

    • 更强大的主机:垂直扩展,更好的机器。

    • 拆分负载:按业务拆分成不同的微服务

    • 分散风险:数据跨机房,异地备份等

    • 负载均衡:避免服务单点故障

    • 作业分离:Job独立服务执行

    • 重新设计:一般设计系统需要考虑10倍容量增长。重新设计系统应对规模化,是成功的标志。

    7、扩展数据库

    • 服务的可用性

    • 服务的持久性:多副本

    • 读取数据扩展:读写分离

    • 写操作扩展:分表分库

    • 共享数据库设施:容易形成单点故障

    • CQRS:命令查询职责分离

    8、缓存的使用

    通过存储之前的操作结果,以便后续请求使用这个结果,而无需花重新计算或查询。

    客户端缓存

    客户端缓存获取的结果,客户端决定何时获取新副本。一般是有下游服务提供缓冲的过期时间。客户端缓存可以减少网络调用次数,并且减少下游服务负载的最快方法之一,客户端缓存数据,让数据失效需要做额外的工作。

    服务端缓存

    服务端来负责处理缓存,容易跟踪和优化缓存的命中率。

    代理服务器缓存

    缓存在服务的和客户端之间,比如方向代理或CDN等。对一切客户端和服务端不透明

    HTTP缓存

    为写使用缓存

    先写入本地缓存,之后某个时刻将数据写入下游的,可能更规范化的数据源中。

    为弹性使用缓存

    下游服务不可用,客户端可以缓存可能失效的数据。

    隐藏源服务

    保护源服务,不直接暴露源服务。如果缓存不命中,立即失败,异步重建缓存。

    保持简单

    避免太多地方使用缓存,缓存越多,数据越可能失效,就越难保证数据的新鲜程度。

    9、自动伸缩

    响应型伸缩、预测型伸缩

    10、CAP定理

    在分布式系统中有三方面需要彼此权衡:一致性、可用性和分区容忍性。这个定理告之我们最多只能能保证三个中的两个。CA系统在分布式系统中根本不存在。

    六、阶段总结:

    在第一部分我们重点介绍了涉及微服务的一些思想,总结了如何设计一个相对好的服务,并且也介绍了一些微服务和领域驱动的相关概念帮助大家学习掌握。

    那么在第二部分介绍中,我将在如何在微服务中使用事务,自动化测试怎么做,Devops是什么,如何利用康威定律管理团队,以及重点介绍实战项目,如何基于Spring boot/netflix来构建微服务项目。

    展开全文
  • WCF从理论到实践系列文章索引

    千次阅读 2008-09-03 09:20:00
    WCF从理论到实践系列文章是笔者记录学习WCF历程的一部笔记,至今已有30余篇,涉及WCF技术绝大多数相关理论知识和丰富的实践实例。这篇索引对上述文章做了一下整理工作,以进一步熟悉掌握WCF技术第一部分:理论1. ...
     WCF从理论到实践系列文章是笔者记录学习WCF历程的一部笔记,至今已有30余篇,涉及到WCF技术绝大多数相关理论知识和丰富的实践实例。这篇索引对上述文章做了一下整理工作,以进一步熟悉掌握WCF技术
    

    第一部分:理论

    1. WCF从理论到实践(1):揭开神秘面纱

    作为系列文章开篇,本文介绍了WCF的概念和发展史,通过学习本文,可以了解以下知识:

    WCF是什么?

    WCF能干什么?

    WCF的今生前世?

    学习WCF有哪些资源?

    2.WCF从理论到实践(2):新老技术对比

    WCF是MS在SOA方面技术的集大成者,整合了以往的几种分布式开发技术,比如XML Web Service,.Net Remoting,Com+,WSE,但这种整合却又不是简单的叠加,WCF仍然具有独具匠心的特征,通过学习本文,可以了解如下知识:

    WCF与以往的分布式技术有何区别?

    WCF 在安全性方面做了哪些改进?

    WCF在性能方面有那些改进?

    WCF开发模型和以往的其他分布式技术有何区别?

    3.WCF从理论到实践(3):契约

    从本文开始,正式介绍WCF相关基础知识,契约(Contract)作为终结点(Endpoint)重要组成ABC中的C,了解它对学习WCF基础知识非常重要。通过学习本文,可以了解如下知识:

    什么是契约?

    契约有几种?,他们都有什么用途

    如何定义契约?

    契约是独立于平台的么?

    契约和以往哪种技术比较相像,又有什么不同?

    4.WCF从理论到实践(4):地址

    作为Endpoint的组成ABC中的A,地址(Address)也不折不扣是WCF技术最重要的基础概念,它标示着服务和元数据的位置,通过学习本文,可以了解如下知识:

    Address是什么?

    Address的组成?

    如何在配置文件中指定Address?

    如何通过编程方式设置Address?

    Address有什么特殊应用?

    5.WCF从理论到实践(5):绑定细解

    作为Endpoint的组成ABC中的B,地址(Binding),绑定是WCF技术最神奇的一个组成部分,通过学习它,能看出软件到底应该是如何构件的,领略到搭积木的方式做程序是何等的享受,

    WCF中的Binding是什么?

    Binding的组成?

    Binding Element 的分类?

    Binding描述了那些层面的信息?

    选择正确的Binding

    6.WCF从理论到实践(6):WCF架构

    前面几篇分别介绍了WCF技术的相关知识和重要的基础知识,是从点说起,本文从面上剖析WCF技术,了解一下它的架构使我们对其有一个更全面,系统的认识,通过学习本文,可以了解如下知识:

    WCF的架构图

    WCF架构的关键元素及其概念

    创建一示例程序,并对其按架构图进行解析

    7.WCF从理论到实践(7):消息交换模式

    作为一门分布式开发技术,WCF首先要解决消息交换的问题,了解消息交换模式对于我们在实践中分析和解决问题都有帮助,通过学习本文,可以了解如下知识:

    WCF定义了哪几种消息交换模式?

    One-Way Calls

    Request/Reply

    Duplex

    用示例来解析WCF的消息交换模式

    8.WCF从理论到实践(8):事件广播

    上文谈及消息交互模式,其中最复杂的莫过于Duplex了,本文用一个示例来阐述Duplex的工作原理,通过学习本文,可以了解如下知识:

    如何实现一个基于duplex的事件广播

    解析在实现duplex事件广播中的几个问题

    初步探讨一下异步

    9.WCF从理论到实践(9):实例模式和对象生命周期

    了解远程对象实例的创建和其生命周期对分析解决实际工作中WCF一些问题有很大帮助,通过学习本文,可以了解如下知识:

    WCF中有哪几种对象实例模式?

    几种实例模式下对象的生命周期?

    各种实例模式的应用场合?

    使用不同的实例模式,需要注意的有哪些?

    代码不骗人,用一个小范例来看看不同实例模式的区别?

    10.WCF从理论到实践(10):异常处理

    服务端的异常如何传递给客户端,以何种方式传递给客户端,客户端收到异常之后,如何更好的排查错误,这些对于WCF项目的实施至关重要,通过学习本文,可以了解如下知识:

    WCF中存在哪几种异常处理方式?

    各种异常处理所适用的应用场合?

    WCF中常见的异常类型?

    代码不骗人,用示例来演示效果,加深印象

    11.WCF从理论到实践(11)-异步访问

    .Net中的异步编程模型APM能极大的改善用户体验和太高系统吞吐量,基于Socket底层的异步通讯机制,WCF实现的异步操作乃是真异步,通过学习本文,可以了解如下知识:

    如何在WCF中实现异步

    异步操作的优缺点及其应用场合

    总结对比各种异步操作的实现方式

    代码不骗人,实现一个WCF异步小范例

    12.WCF从理论到实践(12):事务

    分布式开发中,事务同样重要,一些操作组成具有原子性,但尤其处于分布式环境中,事务的使用就更加复杂,通过学习本文,可以了解如下知识:

    如何在WCF中实现事务?

    谈谈事务隔离方式的相关知识

    事务的实现会给我们编程带来什么样的阻力?

    13.WCF从理论到实践(13):事务投票

    该篇是对上文事务介绍的一个有利补充,通过一个实例讲解事务是如何根据商业逻辑被提交的,通过学习本文,可以了解如下知识:

    进一步学习WCF事务

    顺便体验一下WPF

    14.WCF从理论到实践(14):WCF解决方案模板

    正所谓磨刀不误砍柴工,本文实现一个通用的WCF解决方案,使用它,可以节省一些不必要的重复工作。

    15.WCF从理论到实践(15):响应变化

    作为一门先进的开发技术,WCF具有很强大的扩展性和拍错性,在一些特殊的应用场合,它能够为我们解决实际问题提供很多有意义的参考,本文只是从几个小的应用场景来阐述WCF的先进性。

    16.WCF从理论到实践(16):操作重载(带视频+ppt+源码)

    作为一门分布式开发技术,它是基于OO的,但却又高于OO,本文便介绍一下操作重载这个面向对象中的常用技术在WCF中的表现,而且本文提供视频和ppt的支持,通过学习本文,可以了解如下知识:

    什么是操作重载?操作重载有什么好处

    WCF的服务端如何解决操作重载的问题?

    WCF的客户端如何解决操作重载问题?

    小结

    17.WCF从理论到实践(17):OO大背离(带视频+ppt+源码)

    上文也说到WCF基于OO,高于OO,本文对这点再次进行讨论.

    第二部分:实践

    实践部分文章索引为:

    1)Ajax访问Xml Web Service的安全问题以及解决方案

    2)Ajax与WCF交互-WCF之美

    3) Ajax与Wcf交互-JSON

    4) ExtJs与WCF交互:生成树

    5) 用ExtJs+Linq+Wcf打造简单grid

    6) ExtJs+WCF+LINQ实现分页Grid

    7) ExtJs与WCF之间的跨域访问

    8) 异步调用Restful的WCF服务

    9) 用Restful方式调用WCF进行上传下载

    10) 再说ExtJs与WCF之间的跨域访问

    11) [添砖加瓦]:ExtJS+WCF+LINQ打造全功能Grid

    12) 【封装】WCF+LINQ+ExtJS做更简单的Grid

    第三部分:特别栏目

    WCF技术研究团队诚邀您的加入

    team

    WCF是"Windows Communication Foundation "的缩写,原来的代号为"Indigo",它是MS为SOA(Service Oriented Architecture)而设计的一套完整的技术框架。利用它能够轻松的开发出分布式(Distributed)应用程序。该技术是MS以往的分布式开发技术的集大成者,优点多多,同时也是.net 3.0中最重要的一个组成部分,目前很多人在学习这门技术,本团队就是想更方便的方便大家学习交流WCF技术。

    WCF技术研究团队QA专题

    qa

    WCF是一门技术,学习它的过程之中,肯定会遇到各式各样的问题,遇到问题了怎么办?我们的团队中有很多高人,而且他们喜欢分享,比如 ArtechAnytaowebabcd等等,不能一一道尽,而且会有越来越多的喜欢分享的朋友加入,我们团队的目的也在于交流,互动,共同学习,所以我想开这么一个专题,专门用来大家提问和回答

    作者:jillzhang
    出处:http://jillzhang.cnblogs.com/
    本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。  
    展开全文
  • 计算机字符编码详解——从理论到实践

    万次阅读 多人点赞 2016-09-24 17:52:39
    最近在看《深入理解计算机系统》,读“字符编码”时不禁想起了初学时那段痛苦的岁月,同时又没找到一篇将理论实践结合在一起的文章,为此决定自己写一份。希望能把我走过的弯路总结出来,能帮助一些还在路上的...

    前言


    最近在看《深入理解计算机系统》,读到“字符编码”时不禁想起了初学时那段痛苦的岁月,同时又没找到一篇将理论和实践结合在一起的文章,为此决定自己写一份。希望能把我走过的弯路总结出来,能帮助一些还在路上的朋友。
    关于计算机如何存储信息,请参考《深入理解计算机系统》的第 02 章内容,此文只讲解与字符编码有关的内容。
    另外,关于常用编辑器对于字符编码的区别,请参考我的另一篇文档——《Win记事本、Sublime、Notepad++等编辑器对常见字符编码的处理和区别:GB2312、GBK、ANSI、Unicode、UTF-8》,此处也不再赘述。


    字符的表示原理


    简单说,计算机内所有信息都是使用0和1进行表示的对于一个短路来说,0代表关,1代表开。那把这些电路组合起来就可以有长串0和1组成的二进制数字,我们对这些数字进行编码和解码,我们就能用它来表示我们想要表示的东西了。比如:文字、图像、视频等等,就是一组0和1的二进制序列。
    二进制数的每一个位表示一个计算机位(bit,简称位),8个位组成一个字节(byte)。那么一个字节可以表示256种含义(2*2*2*2*2*2*2*2=256)。

    虽然机器是基于二进制的,但对人类来说,因为二进制数太长了,需要做精简。因此需要将其转换成十六进制(hexadecimal,简称hex)。转换方式很简单,使用“8421法”将四位二进制数转换成十六进制数的一位,比如:1010(binary)会转为A(hex)。在 C 语言中,十六进制数以”0x”或“0X”开头,A表示10,F表示16。

    此后,00000000~11111111就可以用0x00~0xFF来表示了。


    常见的字符编码

    ANSI是美国国标的英文字符编码,占用一个字节,收录了127个字符。
    原理很简单,用一个字节的不同的值表示一个字符、字母或数字。

    文字开头有不可见的标志码,用于告知下文应该以什么方式解码。
    文中所有字符编码都是这种方式。

    英文字符编码占用一个字节就够了,但对于像中文、日文这种象形文字国家一个字节就肯定不够了。为此,中国的国标字符编码需要占用 2 个字节,中国标准局依次发布了GB2312、GBK、GB18030等。

    虽然每个国家或地区的字符编码自行搞定了,但是多个国家间还是不能兼容。为此Unicode编码应运而生,它整合全世界的几乎所有语言文字。

    下面我们依次讲解下ANSI、GB2312、GBK、GB18030、Unicode、UTF-8等编码。

    ANSI编码

    ANSI码占用1个字节,收录127个字符,取值范围0x00~0x7F

    ANSI编码表:
    这里写图片描述

    GB2312、GBK、GB18030

    发布顺序依次为:GB2312、GBK、GB18030。都以ANSI格式存储

    彼此区别:

    • GB2312是常用简体汉字;
    • GBK基于GB2312,包含更多生僻字,支持简繁双体
    • GB18030基于GBK,包含更多生僻字,支持少数民族文字,支持CJK(中日韩)统一字符。
    • GB2312和GBK都是双字节,GB18030分单、双、四字节三个部分。


    比如:在GB2312上没有“喆”,在GBK上才被收录。

    因这三种编码规则差不多,下面我们重点讲解下GB2312。


    GB2312

    考虑到以下因素:

    • ANSI范围是:0x00~0x7F。
    • 国际通用精确数字计算使用的BCD编码范围是:0x00~0x99。

    为避免冲突,要预留一定空间,GB2312的范围:0xA0~0xFF

    GB2312:

    • 又称GB0,国标局发布,1981年5月1日实施。
    • 收录6763个汉字:一级汉字3755个,常用字,排在前面;二级汉字3008个,生僻字,排在后面。
    • GB2312是一种区位码。分为94个区(01-94),每区94个字符(01-94)。
      • 01-09区为特殊符号;
      • 10-15区没有编码;
      • 16-55区为一级汉字,按拼音排序,共3755个;
      • 56-87区为二级汉字,按部首/笔画排序,共3008个;
      • 88-94区没有编码;
      • GB2312只是编码表,在计算机中通常都是用”EUC-CN“表示法,即在每个区位加上0xA0来表示。区和位分别占用一个字节。

    EUC-CN表示法:

    • EUC-CN是GB2312最常用的表示方法。
    • GB2312字元使用两个字节来表示, 每个字节=0xA0+区位码。
    • “第一位字节”取值范围:0xB0~0xF7
    • “第二位字节”取值范围:0xA1~0xFE

    举例来说,“啊”字是GB 2312之中的第一个汉字,它的区位码是1601
    在EUC-CN之中,它把0xA0+16=0xB0;0xA0+1=0xA1;得出0xB0A1

    GB2312的中文区位的首末两位是特意空出来的。原因是:

    • 首位(0x00):在ANSI中表示空,中国人更习惯从1开始计数,而不是从0开始计数。
    • 末位(0xFF):代表结束,因为有些程序员会将其定义为空,因此空出以避免冲突。

    GB2312中文编码页的排列方式:
    这里写图片描述

    GB2312的编码表请参考以下链接:GB2312汉字编码字符集对照表

    《关于Windows记事本与Sublime Text对中文字符编码转换的问题》:

    先对Windows记事本做个小实验:

    1. 在Windows记事本中,新建文件,输入“你好hello1234”,以ANSI格式保存后;
    2. 在Sublime Text中打开此文件,文件格式为GB2312,输入GB2312内不支持的汉字“喆”,提示保存失败,原因是’\u5586’是非法的多字节序列;
      ’gb2312’ codec can’t encode character ‘\u5586’ in position 11: illegal multibyte sequence
      第 11 个字符就是“喆”。
      注意:如果不删除这个字段,Sublime Text会以UTF-8格式重新保存这个文件。

    3. 在Windows记事本中,输入GB2312内不支持的汉字“喆”,按ANSI格式保存成功;

    4. 再次用Sublime Text打开此文件,文件格式已变为GBK。

    综上,在Windows记事本中,GB2312和GBK是统一以ANSI方式管理的。我猜测,Windows记事本默认使用GB2312存储汉字,如遇到GB2312不能识别的生僻字才会使用GBK格式存储。

    Sublime Text并不支持这种功能,如果你强行输入“喆”字以后,会有错误框弹出。然后,它会把这个文件转换为UTF-8格式并保存。
    因为Sublime Text默认是支持UTF-8编码,不支持GB2312、GBK等中文编码,需要安装ConvertToUTF-8插件才能实现。显然,ConvertToUTF-8并没考虑这种情况。

    在Sublime Text中以GB2312格式无法存储没被收录的字符:
    在Sublime Text中以GB2312格式无法存储没被收录的字符

    Unicode

    Unicode简介:

    • 统一码、万国码、单一码,包括字符集、编码方案等。
    • 它为每种语言中的每个字符设定了统一并且唯一的二进制编码,以满足跨语言、跨平台进行文本转换、处理的要求。
    • 1990年开始研发,1994年正式公布。
    • 统一码为每个字符而非字形定义唯一的编码(即一个整数),字体视觉展示由其他软件来处理。由此,可解决汉字一字多形的认定争议(如“ɑ/a”、“户/户/戸”等)。

    Unicode与UCS:
    统一编码联盟都试图独立创建一套国际通用的字符编码,此后双方都意识到没必要创建两套编码,于是两者融合并承诺彼此兼容。从Unicode 2.0开始,Unicode采用了与ISO 10646-1相同的字库和字码。

    通用字符集(Universal Character Set, UCS):由ISO制定的ISO 10646(或称ISO/IEC 10646)标准所定义的标准字符集。UCS-2用两个字节编码,UCS-4用4个字节编码。

    简单说,Unicode与UCS-2相同。

    Unicode编码原理:

    UCS-4有4个字节:

    • 第一个字节:表示组(group),最高位为0,则有128个。
    • 第二个字节:表示平面(plane),256个。
    • 第三个字节:表示行(row),256个。
    • 第四个字节:表示码位(cell),256个。


    group 0的是最底层的平面0被称作BMP(Basic Multilingual Plane),即0x0000XXXX(大写X表示任何一个十六进制数字)。

    平面 字符范围 备注
    基本多语言平面 0~0xFFFF BMP, or Plane 0
    增补多语言平面 0x10000~0x1FFFF SMP, or Plane 1
    增补表意字符平面 0x20000~0x2FFFF SIP, or Plane 2
    增补专用平面 SSP, or Plane 14

    注意:

    • BMP:Basic Multilingual Plan
    • SMP:Supplementary Multilingual Plane
    • SIP:Supplementary Ideographic Plane
    • SSP:Supplementary Special-purpose Plane

    当UCS-4的前两个字节为全零(BMP)时,那么去掉UCS-4的前两个零字节就得到了UCS-2。

    在Unicode中,有几种方式唯一编码数字的转换格式:UTF-8、UTF-16、UTF-32。
    UTF(Unicode Transformation Format),可以翻译成Unicode字符集转换格式,即怎样将Unicode定义的数字转换成程序数据。


    例如,“汉字”对应的数字是0x6c49和0x5b57,而编码的程序数据是:

    char      data_utf8[]={0xE6,0xB1,0x89,0xE5,0xAD,0x97};  //UTF-8编码
    char16_t data_utf16[]={0x6C49,0x5B57};                  //UTF-16编码
    char32_t data_utf32[]={0x00006C49,0x00005B57};          //UTF-32编码

    注: char16_t 和 char32_t 是 C++ 11 标准新增的关键字。如果你的编译器不支持 C++ 11 标准,请改用 unsigned short 和 unsigned long。

    “汉字”的UTF-8编码需要6个字节。
    “汉字”的UTF-16编码需要两个char16_t,大小是4个字节。
    “汉字”的UTF-32编码需要两个char32_t,大小是8个字节。

    UTF-8

    Unicode编码(十六进制) UTF-8 字节流(二进制)
    00000000 - 0000007F 0xxxxxxx
    00000080 - 000007FF 110xxxxx 10xxxxxx
    00000800 - 0000FFFF 1110xxxx 10xxxxxx 10xxxxxx
    00010000 - 001FFFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
    00200000 - 03FFFFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
    04000000 - 7FFFFFFF 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

    UTF-8的特点是对不同范围的字符使用不同长度的编码,兼容ASCII编码。

    • 对于0x00-0x7F之间的字符,UTF-8编码与ASCII编码完全相同。
    • UTF-8编码的最大长度是6个字节。
    • 从上表可以看出,6字节模板有31个x,即可以容纳31位二进制数字。Unicode的最大码位0x7FFFFFFF也只有31位。

    例1:
    “汉”的Unicode编码是0x6C49,在0x0800-0xFFFF之间,使用3字节模板:1110xxxx 10xxxxxx
    10xxxxxx。 0x6C49的二进制表示为:0110 1100 0100 1001,
    用这个比特流依次代替模板中的x,得到:11100110 10110001 10001001,即E6 B1 89。


    例2:Unicode编码0x20C30在0x010000-0x10FFFF之间,使用4字节模板:11110xxx 10xxxxxx
    10xxxxxx 10xxxxxx。将0x20C30写成21位二进制数字(不足21位就在前面补0):0 0010 0000 1100
    0011 0000,用这个比特流依次代替模板中的x,得到:11110000 10100000 10110000 10110000,即F0
    A0 B0 B0。

    UTF-16

    根据字节序的不同,UTF-16可以被实现为UTF-16BEUTF-16LE(Windows系统默认)。

    Win32的API提供两种调用方式:

    • 以W结尾的函数:使用UTF-16LE编码模式;
    • 以A结尾的函数:使用多字节编码模式(中文编码是以ANSI格式存储的),但是Windows会在底层将其转换为UTF-16LE编码来处理。

    因此对于Windows编程来说,最好默认使用Unicode(UTF-16LE)模式开发,避免系统底层多余的字符转换。

    Unicode字符编码范围 UTF-16 单个字符长度 备注
    U+0000~U+FFFF 1个16位编码单元 16位无符号整数,固定宽度,BMP中的字符
    U+10000~U+10FFFF 2个16位编码单元 称作代理对(surrogate pair),变宽

    UTF-16是早期Unicode遗留下的历史产物,原本被设计成具有固定宽度的16位编码格式。为支持超过U+FFFF的增补字符,设立了代理机制。

    编码转化规则

    UTF-16编码以16位无符号整数为单位。我们把Unicode编码记作U。编码规则如下:

    • 如果U<0x10000,U的UTF-16编码就是U对应的16位无符号整数。
    • 如果U≥0x10000,
      • 我们先计算U’=U-0x10000,
      • 然后将U’写成二进制形式:yyyy yyyy yyxx xxxx xxxx,
      • U的UTF-16编码(二进制)就是:110110yyyyyyyyyy 110111xxxxxxxxxx。

    为什么U’可以被写成20个二进制位?
    Unicode的最大码位是0x10FFFF,减去0x10000后,U’的最大值是0xFFFFF,2的5次幂是32,所以肯定可以用20个二进制位表示。

    例如:Unicode编码0x20C30,减去0x10000后,得到0x10C30,写成二进制是:0001 0000 1100 0011
    0000。用前10位依次替代模板中的y,用后10位依次替代模板中的x,就得到:1101100001000011
    1101110000110000,即0xD843 0xDC30。

    UTF-32

    根据字节序的不同,UTF-32可以被实现为UTF-32LE或UTF-32BE。

    UTF-32是一种最简单的Unicode编码格式。每个Unicode码点被直接表示为一个32位的编码单元。UTF-32是一种固定宽度的字符编码格式。
    每个UTF-32编码单元的值与Unicode码点的值完全相同。

    因为对于多数情况下,非常浪费空间,因此应用场景很少。


    各编码间的转换


    总结


    参考文献

    深入理解计算机系统——第02章——信息的表示和处理
    GB2312的区位码是94的来历
    GB2312汉字编码字符集对照表
    “字节序”是个什么鬼?
    字符编码笔记:ASCII、Unicode、UTF-8、UTF-16、UCS、BOM、Endian
    Unicode汉字对应表
    US-ASCII和ISO-8859-n 控制字符表
    Unicode字符编码标准


    展开全文
  • 2019-2020-2学期机器人工程专业需要开设SLAM技术课程,使用教材为视觉SLAM十四讲从理论到实践第二版。 为方便学生学习课程知识,将Arduino、ROS1、ROS2和SLAM集成课程定制版镜像中。链接如下: ...
  • 本文节选自图书《视觉SLAM十四讲:从理论到实践》 本文完全由实践部分组成,实际书写一个视觉里程计程序。你会管理局部的机器人轨迹与路标点,并体验一下一个软件框架是如何组成的。在操作过程中,我们会遇到许多...
  • 数据治理-从理论到实践(一)

    千次阅读 2019-04-01 16:48:13
    大数据治理范围 一、背景概述 1.数据治理 由于切入点和侧重点,业内给予了不同的见解。 广泛认可标准:DMBOK、COBIT 5、...数据治理不是一门技术,而是逻辑性很强的理论型学科。 1.1大数据治理 Sunil Soares ...
  • //reactor.core.publisher.Mono public final Disposable subscribe( @Nullable Consumer<? super T> consumer, @Nullable Consumer<? super Throwable> errorConsumer, @Nullable Runnable ...
  • 79页区块链报告:从理论到实践(附下载)

    千次阅读 热门讨论 2018-01-30 00:00:00
    前言高盛公司(Glodman Sachs)曾发布过报告《区块链:从理论走向实践》(Block chain: Putting Theory intoPractice),报告显示,硅谷和华尔街都为了区块链着迷,逐渐忘记了作为其技术源头的比特币。但对其潜在...
  • HOG:从理论到OpenCV实践

    万次阅读 多人点赞 2014-03-11 22:56:37
    ...一、理论 1、HOG特征描述子的定义:  locally normalised histogram of gradient orientation in dense overlapping grids,即局部归一化的梯度方向直方图,是一种对图像局部重叠区
  • 公众号后台回复:“区块链”,获取本文报告热门推荐:工信部发布《区块链数据格式规范》标准中国首个区块链标准《区块链参考架构》发布高盛公司曾发布过报告《区块链:从理论走向实践》,报告显示,硅谷和华尔街都...
  • 关注公众号,后台回复“区块链高盛” 可直接获取《区块链:从理论走向实践》(Block chain: Putting Theory intoPractice)下载链接,更多资料下载见公众号菜单。高盛公司(Glodman Sachs)曾发布过报告《区块链:...
  • SVM:从理论到OpenCV实践

    万次阅读 多人点赞 2014-02-28 16:59:59
    一、理论 参考网友的博客: (1)【理论】支持向量机1: Maximum Margin Classifier —— 支持向量机简介 (2)【理论】支持向量机2: Support Vector —— 介绍支持向量机目标函数的 dual 优化推导,并得出“支持向量”...
  • front/pop从理论到实践

    万次阅读 2009-02-25 00:51:00
    STL的std::queue说起STL的std::queue类是个容器适配器,即由其它容器包装而成的特殊数据结构。提到queue,就少不了提及它的两个最重要的操作:往队列尾部填加数据的push和队列头部弹出数据的pop。本文不打算讨论...
  • ## 拷贝哨兵配置文件 cp sentinel.conf /etc/redis/ ## 配置哨兵的配置文件 vim /etc/redis/sentinel.conf

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 292,386
精华内容 116,954
关键字:

从理论到实践再从实践到理论