• Linux下矩阵键盘驱动分析与移植

    本文出自:【InTheWorld的博客】

    首先要介绍一下Linux中input子系统的模型,一图胜千言,所以直接上图。

    input_subsys

    上图一目了然,我们的键盘驱动就是工作在input子系统的最低层。单纯地从驱动角度讲,我们的工作就是最终调用input_event()这个函数,把扫描到的键值传递给input core层。然后的事情就不是我们考虑的了,这样一来感觉很轻松的样子。

    好吧!正式开工了!首先说明一下硬件环境,我用的是友善之臂的tiny210开发板。出厂配置的内核是没有加入矩阵键盘的。不过驱动代码是有的,所以在menuconfig里面配置矩阵键盘。说实话,这工作真的很弱智的样子。为什么呢?因为210处理器上是有一个键盘控制器一样的东西。什么扫描,消抖都是硬件在干。唯一需要改动的地方就是键盘的键值表。默认的驱动里面只用44的键值数据,但是我要用的键盘要88才行。

    然后我们分析一下驱动的结构,键盘在210上是作为一个平台设备存在的。那么… 【查看更多】

  • Java的序列化实现解析

    本文出自:【InTheWorld的博客】java_logo

    对于Java自带的对象序列化,我并没有仔细研究过它的实现机制。对于Java默认的序列化机制,它的最大优点就是简单方便。你需要做的仅仅是对需要序列化的POJO增加一句implement Serializable,最多最多再增加一行serialVersionUID。其他的事情就不用我们操心了。那么Java默认的序列化机制是如何实现的呢?答案就是——反射。

            Person person = new Person(25, "Tim");
            FileOutputStream fos = new FileOutputStream("Person.txt");
            ObjectOutputStream oos = new ObjectOutputStream(fos);
            oos.writeObject(person);

    上面这段代码是典型的默认序列化使用方式。玄机就… 【查看更多】

  • TCP粘包与拆包——基于Netty

    本文出自:【InTheWorld的博客】

    netty_log

    粘包与拆包的概念

    在TCP/IP协议中,由于传输层并不了解应用层数据的含义,发送端传输层可能会对应用层数据进行拆分或者合并,在接收端也同样如此。由此而产生的问题就是常常会听说的“粘包与拆包”的问题。“粘包拆包”的问题在“短报文”和“一问一答”的场景下其实并不会出现。短报文是指报文长度远小于MSS的情况,应用层的报文在TCP报文中完全可以放下。另一方面,“一问一答”的通信模式可以保证报文会以单一的TCP包发送出去。在这两个条件下都满足时,我们不需要考虑“粘包拆包”问题。

    反之,如果这两个条件不同时满足,就很可能会出现“粘包拆包”问题。

    • 粘包的示意图

    220649_ivTz_1759553

    • 拆包的示意图

    221054_Pifu_1759553

    粘包拆包的问题的原因大概有以下几个方面:

    1. 应用程序要写入的报文字节数大于套接字缓存区大小,这时候会发生拆包问题。
    2. 应用程序的报文字节数小于套接字
    【查看更多】
  • SSL/TLS的理解与使用

    本文出自:【InTheWorld的博客】

    随着网络安全技术的发展,SSL(Secure Socket Layer)逐渐成为了一种广泛应用的技术。甚至我个人认为,SSL已经成为软件从业人员必须要理解的技术。回想起来,我为了学习SSL技术还是花了不少的时间。可惜应用的少,所以很多知识点都开始淡忘了。前几天,同事们在讨论SSL的问题,我没忍住就参合了进去,大致的讲了一下自己对SSL的一些理解,也讨论了一些相关问题。这些交流也算是简单复习了一下SSL方面的知识吧!期间也发现了自己对相关知识点有些生疏了,所以就准备写点关于SSL的问题。这篇算是个人第一篇关于网络安全的blog了。image

    关于历史发展的内容,我就不赘述了。还是直接上SSL的通信流程图了,上图展示了完整的SSL通信过程。下面结合上图解释一下SSL的整个流程。

    1. 发送的第一条消息为 ClientHello,其中包含了客户端所推荐的加密参数,
    【查看更多】
  • Varnish缓存服务器的使用

    本文出自:【InTheWorld的博客】varnishcache (1)

    我最早接触CDN的概念是看阿里“叔度”的分享,当时觉得CDN很有趣的。后来也看过一本移动研究院出的CDN书,但还是对CDN缺乏细致的了解。双十一的时候,趁着减价的时机,入手了一台阿里云的ECS服务器。这个blog的速度确实不敢恭维,所以昨天晚上开始着手给网站提提速。

    刚开始我打算用LuManager来实现,后来又觉得LuManager这种面板操作确实有悖于自己学习的目的。而且,阿里上的这台ECS内存有两个G,感觉做一个内存层面的cache还是可以的。所以最终还是决定使用先玩一玩Varnish。Varnish这个软件其实挺出名的。

    如果要说Varnish的原理,其实就是反向代理 + 内存缓存。大致的架构图如下图所示:

    5243fbf2b2119313f8f3d19667380cd791238d67

    我的web服务器是在西雅图,是一台相当低配的VPS,而反向代理服务器(即Varnish)【查看更多】

  • NDK开发的入门级总结

    本文出自:【InTheWorld的博客】

    就在两天前,我对JNI或者NDK开发的了解基本都还处于Hello World水平。这两天花时间学习了一下,算是对NDK开发有了一些入门级的了解。所以我准备写这一篇博客,算是一个入门级的学习总结。鉴于目前的水平,这篇blog不会讨论到一些复杂的内容,仅仅是一些流程的理解和分析。


    • JNI和NDK的开发思路

    NDK听起来好像很神秘,但实质上就是Java调用C/C++代码的技术。考虑到JVM就是用C/C++写的,Java调用C/C++其实并没有本质上的难度。以前写过一篇关于Lua调用C扩展的博客,其实就和JNI的思路是差不多的,当然Java比Lua复杂的多。JNI本质上就是这种调用的支持接口,在展开这种支持接口的使用方法之前,先来探讨一下这种接口的实现思路。

    虽然JNI已经明确的定义了接口函数的设计标准,但具体的实现还是有很多门道的【查看更多】

  • RxAndroid解析

    本文出自:【InTheWorld的博客】

    首先说明,RxAndroid其实并不是一个大项目,它更接近于一个RxJava在Android平台的一个补丁。不过这个霸气的名字却容易让人感觉这个一个平行的大项目。其实RxJava在Android上特殊性主要体现在UI线程的切换上,因为Android不允许普通线程更新UI。所以,RxAndroid的主要功能其实就是实现了AndroidSchedulers的功能。对于AndroidSchedulers这个类而言,我们最熟悉的用法便是AndroidSchedulers.mainThread()这个方法了。

    public final class AndroidSchedulers {
        private static final AtomicReference INSTANCE = new AtomicReference();
        private final Scheduler
    【查看更多】
  • RxJava原理之Scheduler

    本文出自:【InTheWorld的博客】

    线程的切换是RxJava一个重要的特性,并行运算和指定线程运行都是基于这种特性的。 其中,RxJava使用Scheduler类来抽象执行体(线程或者线程池)。而指定Scheduler的方式有observeOn()和subscribeOn()这两种。本文的标题是关于Scheduler原理方面的,但是直接去看Scheduler的实现其实是一种比较笨的办法。因为Scheduler其实是一个功能类,从使用方式上研究是一种更容易的方式。所谓的使用方式其实就是observeOn()和subscribeOn()这两个方法了。

    • observeOn方法

    废话少说,还是先来看一个observeOn()方法的使用例子吧!

        public static void main(String[] args) {
            Observable.range(20, 5)
                .doOnEach(debug("number",
    【查看更多】
  • mDNS浅析及应用

    本文出自:【InTheWorld的博客】

    mDNS是multicast DNS,mDns实现了在局域网内的服务发现功能。mDNS协议应用非常广泛,其中苹果的Bonjour就是mDNS的一个实现,此外Android 4.1之后也加入了对mDNS协议的支持。那么不禁要问,mDNS是如何实现局域网内的服务发现功能的呢?其实答案就在问题中,multicast + DNS。

    mDNS协议基于多播网络技术,它工作于UDP的5353端口。mDNS选择多播作为其实现方式,是有一定原因的。首先 ,单播网络不适合用于局域网络的服务 ,因为单播是点对点的,而服务的信息却应该面向多个客户的。其次,广播也是有局限的,为了避免广播风暴,广播是不能穿越子网的。所以mDNS选择多播技术的主要原因是多播面向多客户端、以及子网穿越的特点。多播节省带宽的特性在局域网内其实意义不大。

    • JmDNS的使用与实现

    DNS的内容,我目前还掌握的不多,各种记录的含义并没有仔细了解。所以这里对DNS部分就不做过多的分析了,… 【查看更多】

  • 线程同步技术之RCU

    本文出自:【InTheWorld的博客】

    多核程序设计其实挺困难的,就拿RCU(Read-Copy-Update)技术来说,我现在已经不知道自己看《深入理解并行编程》的RCU多少次了。到现在为止,还是有一些东西没有完全理解。这篇blog算是对我所领会到的RCU知识的暂时性总结。

    • RCU背景

    从个人的理解来讲,RCU其实是对rwLock的一种优化。从不区分读写的粗粒度锁到读写锁,然后到RCU机制,这就体现着并行程序设计的不断演进。rwLock的思路是,多线程读取不存在同步问题,所以放宽了读取锁,提高了并发读取的效率。而RCU的思路是,维持临界区多个版本(完整的非中间版本),同时取消读取锁,这种优化将会进一步的提高读取效率。事实上,在多数的多线程应用场景上,读取频率都是远远大于改写频率的。特别是在Linux内核中,很多全局数据结构会被同时读取,其次数远高于写入次数。

    image

    Figure… 【查看更多】