RT-Thread发布SAL套接字抽象层，带来全新物联网软件开发模式
当前主流的软件开发模式是怎么样的呢？我们以一个典型的MCU+WiFi/NB-IoT SoC架构的IoT设备开发为例（图示一），开发人员需要针对特定的无线SoC/模块，开发MCU TCP/IP协议层以上的应用，包括MQTT、HTTP、Web Socket、业务类应用等等。
一旦用户更换了无线芯片或模块，因为网络协议、编程接口等的不统一，上层应用都需要做大幅的改动甚至要重头来过。
（图示一：当前的软件开发模式）
而如果采用了RT-Thread操作系统的SAL抽象层（图示二），开发者则无须考虑系统采用的是哪种无线方式、哪种无线芯片、甚至哪种模块，哪种接口，只需调用上层的API接口，即可实现一次开发，跨平台使用。
不仅如此，RT-Thread支持的各种IoT软件包，都可以很方便的“即装即用”。
（图示二：具备SAL的软件开发模式）
以上可见，RT-Thread此次发布的SAL可谓对IoT产业意义重大，真正实现了系统（MCU+无线芯片/模块）层面的跨平台软件开发及兼容，暨ACS（Application Cross System），后期的应用扩展也会变得易如反掌。
SAL，即Socket abstraction layer的缩写，意为套接字抽象层，处于网络硬件层与应用层之间。 其前身是 RT-Thread 的 DFS_NET 组件，由于其对 lwIP 有一定的依赖，存在局限性，RT-Thread对其进行了近乎重构的再造。
SAL 的孕育而出，使得 RT-Thread 可以无缝接入各式各样的网络芯片或模块（例如： W5500/CH395 这类自带协议栈的以太网芯片，带 AT指令的 WiFi 模块、GPRS 模块、NB-IoT 模块等等），极大地提升了RT-Thread 在 IoT 领域对于不同网络硬件的兼容性。其主要特性如下（图示三）：
抽象、统一多种网络协议栈接口
提供标准 BSD Socket API
统一 fd（file descriptor）管理方式
（图示三：网络框架图）
下面将站在与 SAL 相关联的模块角度，说明 SAL 的功能与实现：
应用层 ：应用层在做网络开发时，可以直接使用 SAL 提供的 BSD Socket API 接口。接口层的统一抽象，使 得我们的开发者也可以快速应用 RT-Thread 提供的众多支持 BSD Socket 接口的 IoT 软件包。让我们的用户 在网络编程方面极大的提升了软件的可重用性。
SAL 实现层：该层位于 SAL 的底部，针对不同的模块、芯片或协议栈，完成与 SAL 框架的对接实现。接入完成后，应用层几乎不需要关心真正的网络接入方式，降低了应用层与底层的耦合。
DFS 文件系统层：SAL 与 DFS 紧密结合， Socket 描述符与fd文件描述符可以完全对应起来，实现了fd的统一管理。使得应用层可以通过read/write 、 poll/select 接口操作 Socket 套接字，更加兼容 POSIX 标准。
应用场景：
对接 AT 指令的网络模块
在使用这些 AT 模块做网络开发时，不可避免地会在我们的应用代码中耦合很多与模块相关的 AT 通信代码。这样也会导致，以前使用标准的 BSD Socket 开发过的组件没法被重用过来。
有了SAL，只需要我们针对AT 模块的指令方式，实现 SAL的对接接口（RT-Thread已经提供了常用模块的实现，例如，乐鑫的 ESP8266，移远的 M26），上层应用即可愉快地进行Socket编程了。
这里稍微提一下，RT-Thread 的 AT 组件已具有上述功能，很快将会发布，敬请期待……
对接内置协议栈的网络芯片
随着像 W5500/CH395 这类网络芯片的越来越普及，我们的 MCU 也就不需要跑网络协议栈了，极大地降低了MCU的资源占用情况。可是跟AT模块也有同样的问题，怎么样才能保证应用层依然很简单地使用标准Socket进行编程？这个问题就交给SAL去解决吧。
SAL 造好了适配这些芯片的轮子，会方便我们所有使用 RT-Thread + W5500/CH395 的开发者。
非lwIP的 TCP/IP 协议栈
在一些特殊领域，可能lwIP并不能够满足我们的用户要求。更换 TCP/IP 协议栈就不可避免。正是因为有了 SAL 框 架，新的协议栈，只需要与其对接完毕，上层应用即可放心使用，以前的代码照样也可以被拿来重用。
Socket CAN
Socket CAN 作为Linux上CAN编程的一种方式，它简易易用，编程顺手。很多用户也想在 RT-Thread 上实现 Socket CAN 编程，这个时候就需要 SAL 上场了。只需要我们在底层使用 RT-Thread CAN 设备实现 SAL框架对应的接口即可。
