updated docs

README.md

@@ -1,34 +1,46 @@
 ZeroTier SDK
 ======
 
-ZeroTier-enabled apps and devices.
+ZeroTier-enabled apps, devices, and services.
 
 Secure virtual network access embedded directly into applications, games, and devices. Imagine starting an instance of your application or game and having it automatically be a member of your virtual network without having to rewrite your networking layer. Check out our [Integrations](integrations/) to learn how to integrate this into your application, device, or ecosystem.
 
+The general idea is this:
+	1) Your application starts.
+	2) The API and ZeroTier service initializes inside a separate thread of your app.
+	3) Your app can now reach anything on your virtual network via normal network calls.
+
+It's as simple as that!
+
+***
+
+The SDK couples the ZeroTier core Ethernet virtualization engine with a user-space TCP/IP stack and a carefully-crafted API which intercepts and re-directs network API calls to our service. This allows servers and applications to be used without modification or recompilation. It can be used to run services on virtual networks without elevated privileges, special configuration of the physical host, kernel support, or any other application specific configuration. It's ideal for [containerized applications](../integrations/docker), [games](../integrations/Unity3D), and [desktop/mobile apps](../integrations).
+
+Combine this functionality with the network/device management capabilities of [ZeroTier Central](https://my.zerotier.com) and its associated [API](https://my.zerotier.com/help/api) and we've hopefully created a simple and reliable way for you to flatten and reduce the complexity of your app's networking layer.
+
+The ZeroTier SDK now works on both *x64* and *ARM* architectures. We've tested a beta version for *iOS*, *Android*, *Linux*, and *macOS*.
+
 ## How do I use it?
 
 There are generally two ways one might want to use the service. 
 
- - The first approach is a *compile-time static linking* of our service directly into your application. With this option you can bundle our entire functionality right into your app with no need to communicate with a service externally, it'll all be handled automatically. This is most typical for mobile applications, games, etc.
+ - The first approach is a *compile-time static linking* of our service library directly into your application. With this option you can bundle our entire functionality right into your app with no need to communicate with a service externally, it'll all be handled automatically. This is most typical for mobile applications, games, etc.
 
- - The second is a service-oriented approach where our network call "intercept" is *dynamically-linked* into your applications upon startup and will communicate to a single ZeroTier service on the host. This can be useful if you've already compiled your applications and can't perform a static linking.
+ - The second is a service-oriented approach where our smaller intercept library is *dynamically-linked* into your app upon startup and will communicate to a single ZeroTier service on the host which will relay traffic to and from the ZeroTier virtual network. This can be useful if you don't have access to the app's source code and can't perform a static linking.
 
 ![Image](docs/img/methods.png)
 
 ## How does it work?
 
-We've designed a background tap service that pairs the ZeroTier protocol with swappable user-space network stacks. We've provided drivers for [Lightweight IP (lwIP)](http://savannah.nongnu.org/projects/lwip/) and [picoTCP](http://www.picotcp.com/). The aim is to give you a new way to bring your applications onto your virtual network. For a more in-depth explanation of our technology take a look at our [SDK Primer](docs/zt_sdk_primer.md)
+We've designed a background tap service that pairs the ZeroTier protocol with swappable user-space network stacks. We've provided drivers for [Lightweight IP (lwIP)](http://savannah.nongnu.org/projects/lwip/) and [picoTCP](http://www.picotcp.com/). The aim is to give you a new way to bring your applications onto your virtual network. For a more in-depth explanation of how it works take a look at our [SDK Primer](docs/zt_sdk_primer.md)
 
 ## APIs
 
 **Hook/Intercept**
 - Uses dynamic loading of our library to allow function interposition or "hooking" to re-implement traditional socket API functions like `socket()`, `connect()`, `bind()`, etc.
 
-**SOCKS5 Proxy**
-- Provides an integrated SOCKS5 server alongside the ZeroTier service to proxy connections from an application to resources on a ZeroTier network. For instance, a developer which has built an iOS app using the NSStreams API could add ZeroTier to their application and simply use the SOCKS5 support build into NSStreams to reach resources on their network. An Android developer could do the same using the SOCKS5 support provided in the `Socket` API.
-
 **Direct Call**
-- Directly call the `zt_` API specified in [SDK.h](src/SDK.h). For this to work, just use one of the provided headers that specify the interface for your system/architecture and then either dynamically-load our library into your app or compile it right in. 
+- Directly call the `zt_` API specified in [src/sdk.h](src/SDK.h). For this to work, just use one of the provided headers that specify the interface for your system/architecture and then either dynamically-load our library into your app or statically-link it at compile-time.
 
 
 ***
@@ -82,3 +94,7 @@ We've designed a background tap service that pairs the ZeroTier protocol with sw
 
 ***
 ![Image](docs/img/api_diagram.png)
+
+
+More discussion can be found in our [original blog announcement](https://www.zerotier.com/blog/?p=490) and [the SDK product page](https://www.zerotier.com/product-netcon.shtml).
+If you have any feature or support requests, be sure to let us know [here](https://www.zerotier.com/community/)!

docs/android_unity3d_zt_sdk.md

@@ -1,4 +0,0 @@
-Android / Unity3D + ZeroTier SDK
-====
-
-Comming soon!

docs/api_discussion.md

@@ -1,24 +0,0 @@
-ZTSDK API Options
-====
-
-*This document is under construction*
-
-## APIs
-
-**Hook/Intercept**
-- Uses dynamic loading of our library to allow function interposition or "hooking" to re-implement traditional socket API functions like `socket()`, `connect()`, `bind()`, etc.
-
-**SOCKS5 Proxy**
-- Provides an integrated SOCKS5 server alongside the ZeroTier service to proxy connections from an application to resources on a ZeroTier network. For instance, a developer which has built an iOS app using the NSStreams API could add ZeroTier to their application and simply use the SOCKS5 support build into NSStreams to reach resources on their network. An Android developer could do the same using the SOCKS5 support provided in the `Socket` API.
-
-**Direct Call**
-- Directly call the `zt_` API specified in [SDK.h](src/SDK.h). For this to work, just use one of the provided headers that specify the interface for your system/architecture and then either dynamically-load our library into your app or compile it right in. 
-
-***
-![Image](docs/img/api_diagram.png)
-
-
-The following APIs are available for this integration:
-- `Direct Call`: Consult [src/wrappers/swift/Apple-Bridging-Header.h](../../../../src/wrappers/swift/Apple-Bridging-Header.h).
-- `Hook of BSD-like sockets`: Use BSD-like sockets as you normally would.
-- `Proxy of NSStream`: Create NSStream. Configure stream for SOCKS5 Proxy (127.0.0.1:PORT). Start Proxy. Use stream. An example of how to use the proxy can be found in the example iOS/OSX projects.

docs/docker_linux_testing.md

@@ -1,65 +0,0 @@
-Testing
-====
-
-### Docker Unit Tests
-
-**Running all docker tests**
-Build the docker images:
-`make docker_images`
-
-Run the docker tests from the docker containers
-`make docker_test`
-
-Check the results of the completed tests:
-`make docker_test_check`
-
-***
-Each unit test will temporarily copy all required ZeroTier binaries into its local directory, then build the `sdk_dockerfile` and `monitor_dockerfile`. Once built, each container will be run and perform tests and monitoring specified in `sdk_entrypoint.sh` and `monitor_entrypoint.sh`
-
-Results will be written to the `tests/docker/_results/` directory which is a common shared volume between all containers involved in the test and will be a combination of raw and formatted dumps to files whose names reflect the test performed. In the event of failure, `FAIL.` will be prepended to the result file's name (e.g. `FAIL.my_application_1.0.2.x86_64`), likewise in the event of success, `OK.` will be prepended.
-
-To run unit tests:
-
-1) Disable SELinux. This is so the containers can use a shared volume to exchange MD5 sums and address information. 
-
-2) Set up your own network at [https://my.zerotier.com/](https://my.zerotier.com/). For our example we'll just use the Earth network (8056c2e21c000001). Use its network id as follows:
-
-3) Generate two pairs of identity keys. Each public/private pair will be used by the *sdk* and *monitor* containers:
-
-    mkdir -p /tmp/sdk_first
-    cp -f ./sdk/liblwip.so /tmp/sdk_first
-    ./zerotier-sdk-service -d -p8100 /tmp/sdk_first
-    while [ ! -f /tmp/sdk_first/identity.secret ]; do
-      sleep 0.1
-    done
-    ./zerotier-cli -D/tmp/sdk_first join 8056c2e21c000001
-    kill `cat /tmp/sdk_first/zerotier-one.pid`
-
-    mkdir -p /tmp/sdk_second
-    cp -f ./sdk/liblwip.so /tmp/sdk_second
-    ./zerotier-sdk-service -d -p8101 /tmp/sdk_second
-    while [ ! -f /tmp/sdk_second/identity.secret ]; do
-      sleep 0.1
-    done
-    ./zerotier-cli -D/tmp/sdk_second join 8056c2e21c000001
-    kill `cat /tmp/sdk_second/zerotier-one.pid`
-
-4) Copy the identity files to *tests/docker*. Names will be altered during copy step so the dockerfiles know which identities to use for each image/container:
-
-    cp /tmp/sdk_first/identity.public ./sdk/tests/docker/sdk_identity.public
-    cp /tmp/sdk_first/identity.secret ./sdk/tests/docker/sdk_identity.secret
-
-    cp /tmp/sdk_second/identity.public ./sdk/tests/docker/monitor_identity.public
-    cp /tmp/sdk_second/identity.secret ./sdk/tests/docker/monitor_identity.secret
-
-
-5) Place a blank network config file in the `tests/docker` directory (e.g. "8056c2e21c000001.conf")
- - This will be used to inform test-specific scripts what network to use for testing
-
-After you've created your network and placed its blank config file in `tests/docker` run the following to perform unit tests for httpd:
-
-    ./build.sh httpd
-    ./test.sh httpd
-
-It's useful to note that the keyword *httpd* in this example is merely a substring for a test name, this means that if we replaced it with *x86_64*, *fc23*, or *nginx*, it would run all unit tests for *x86_64*, *Fedora 23*, or *nginx* respectively.
-

docs/faq.md

@@ -1,12 +1,100 @@
-For beginners
+Frequently Asked Questions
-====
+======
 
-## Why would I integrate ZeroTier into my app?
+
+### Why would I integrate ZeroTier into my app?
 
 The ZeroTier SDK is designed specifically for the developer that doesn't want to work with or deal with the headaches of writing a networking layer for their app. Integrating ZeroTier into your application will prevent you from having to figure out how to do the complex networking that your app might require. It will provide you with a secure, easy-to-use, P2P connectivity solution.
 
-### Use in Mobile Apps
+#### Use in Mobile Apps
 If you're writing a game and you'd like to give it the ability talk to other instances in a secure and fast manner, you can embed our library into your app and choose from a couple different APIs. If you're developing for iOS, you'll want to add our [iOS Framework](https://github.com/zerotier/ZeroTierSDK/tree/master/integrations/apple/example_app/iOS) to your project. If you're developing for Android, you'll need to add our [JNI library](https://github.com/zerotier/ZeroTierSDK/tree/master/integrations/android) to your project. Once your app starts up, a separate thread will start which contains the ZeroTier service and a network stack dedicated entirely to your app. Each of these integrations give your app two main options for talking over a ZeroTier network. The first is a "direct call" which is means you'll call functions such as `zt_socket(), zt_connect(), ...` which are reimplementations of the traditional [socket API](https://en.wikipedia.org/wiki/Berkeley_sockets). Alternatively we provide a SOCKS5 proxy server in a separate thread which you can turn on via `zt_start_proxy_server(...)`. And if you've already implemented your networking layer using the traditional socket API and you aren't using third-party libraries that need to make network calls, you can `zt_start_intercept()`. The intercept will essentially hijack your network calls and route them to our reimplementations. This has the advantage that you literally don't have to change a single line of your networking code to use ZeroTier. (NOTE, the intercept is *not* available on Android).
 
-### Use in Desktop Apps
+#### Use in Desktop Apps
 Desktop apps are a bit easier than mobile apps to integrate with ZeroTier and you'll have even more API options. The exact details vary slightly among the various [platforms/OSes we support](https://github.com/zerotier/ZeroTierSDK/tree/master/integrations), but generally you can either link the ZeroTier library into your application (same as mobile), you can use the built-in SOCKS5 proxy (same as mobile), you can use the intercept (so far tested on OSX, Linux), or you can use `LD_PRELOAD` to dynamically load just the intercept into each of your apps and all will talk to a single `zerotier-sdk-service` running on the local host. This last option is a good option if you don't have access to the source code of the application and thus cannot use the direct call or SOCKS5 proxy APIs.
+
+***
+
+
+
+
+
+
+
+### I want technical details on how this all works under the hood.
+ - See [Technical Discussion](docs/technical.md)
+
+***
+
+
+
+
+
+
+
+### I don't have access to my an app's source but I still want to embed ZeroTier into it. Is this possible?
+ - Yes! See []()
+
+***
+
+
+
+
+
+
+
+### I'm not sure which API is best.
+ - 
+
+***
+
+
+
+
+
+
+### How do switch network stacks?
+
+See [Network Stacks](docs/network_stacks.md)
+
+***
+
+
+
+
+
+
+### Suitable for games?
+
+Yes. We think this solution is well suited for low-latency multiplayer games where reliability and ease of use are important.
+
+The ZeroTier protocol is inherently P2P and only falls back to a relay in the event that your direct link is interrupted. It's in our best interest to automatically find the quickest route for your data and to *not* handle your data. This has the obvious benefits of reduced latency for your game, but also provides you better security and control of your data and reduces our costs. It seems non-sensical to do it any other way. ZeroTier is not a "cloud" that you send all of your data to.
+
+We've just begun work on a native [Unity 3D](https://unity3d.com/) plugin to enable your Unity app to communicate over ZeroTier networks. You can check out our BETA [here](../integrations/Unity3D)
+
+***
+
+
+
+
+
+
+### Embedded Applications / IoT
+
+We foresee the largest application of the ZeroTier SDK to be embedded devices that require lightweight, efficient and reliable networking layers that are also secure and effortless to provision. We've specifically engineered the core service and the API library to be as lightweight and portable as possible. We'd like to see people retake control of their data and security by skipping the the "cloud" without adding complexity.
+
+***
+
+
+
+
+
+
+### Controlling traffic?
+
+**Network Containers are currently all or nothing.** If engaged, the intercept library intercepts all network I/O calls and redirects them through the new path. A network-containerized application cannot communicate over the regular network connection of its host or container or with anything else except other hosts on its ZeroTier virtual LAN. Support for optional "fall-through" to the host IP stack for outgoing connections outside the virtual network and for gateway routes within the virtual network is planned. (It will be optional since in some cases total network isolation might be considered a nice security feature.)
+
+***
+
+
+
+

docs/intro.md

@@ -1,34 +1,46 @@
 ZeroTier SDK
 ======
 
-ZeroTier-enabled apps and devices.
+ZeroTier-enabled apps, devices, and services.
 
 Secure virtual network access embedded directly into applications, games, and devices. Imagine starting an instance of your application or game and having it automatically be a member of your virtual network without having to rewrite your networking layer. Check out our [Integrations](integrations/) to learn how to integrate this into your application, device, or ecosystem.
 
+The general idea is this:
+	1) Your application starts.
+	2) The API and ZeroTier service initializes inside a separate thread of your app.
+	3) Your app can now reach anything on your virtual network via normal network calls.
+
+It's as simple as that!
+
+***
+
+The SDK couples the ZeroTier core Ethernet virtualization engine with a user-space TCP/IP stack and a carefully-crafted API which intercepts and re-directs network API calls to our service. This allows servers and applications to be used without modification or recompilation. It can be used to run services on virtual networks without elevated privileges, special configuration of the physical host, kernel support, or any other application specific configuration. It's ideal for [containerized applications](../integrations/docker), [games](../integrations/Unity3D), and [desktop/mobile apps](../integrations).
+
+Combine this functionality with the network/device management capabilities of [ZeroTier Central](https://my.zerotier.com) and its associated [API](https://my.zerotier.com/help/api) and we've hopefully created a simple and reliable way for you to flatten and reduce the complexity of your app's networking layer.
+
+The ZeroTier SDK now works on both *x64* and *ARM* architectures. We've tested a beta version for *iOS*, *Android*, *Linux*, and *macOS*.
+
 ## How do I use it?
 
 There are generally two ways one might want to use the service. 
 
- - The first approach is a *compile-time static linking* of our service directly into your application. With this option you can bundle our entire functionality right into your app with no need to communicate with a service externally, it'll all be handled automatically. This is most typical for mobile applications, games, etc.
+ - The first approach is a *compile-time static linking* of our service library directly into your application. With this option you can bundle our entire functionality right into your app with no need to communicate with a service externally, it'll all be handled automatically. This is most typical for mobile applications, games, etc.
 
- - The second is a service-oriented approach where our network call "intercept" is *dynamically-linked* into your applications upon startup and will communicate to a single ZeroTier service on the host. This can be useful if you've already compiled your applications and can't perform a static linking.
+ - The second is a service-oriented approach where our smaller intercept library is *dynamically-linked* into your app upon startup and will communicate to a single ZeroTier service on the host which will relay traffic to and from the ZeroTier virtual network. This can be useful if you don't have access to the app's source code and can't perform a static linking.
 
 ![Image](docs/img/methods.png)
 
 ## How does it work?
 
-We've designed a background tap service that pairs the ZeroTier protocol with swappable user-space network stacks. We've provided drivers for [Lightweight IP (lwIP)](http://savannah.nongnu.org/projects/lwip/) and [picoTCP](http://www.picotcp.com/). The aim is to give you a new way to bring your applications onto your virtual network. For a more in-depth explanation of our technology take a look at our [SDK Primer](docs/zt_sdk_primer.md)
+We've designed a background tap service that pairs the ZeroTier protocol with swappable user-space network stacks. We've provided drivers for [Lightweight IP (lwIP)](http://savannah.nongnu.org/projects/lwip/) and [picoTCP](http://www.picotcp.com/). The aim is to give you a new way to bring your applications onto your virtual network. For a more in-depth explanation of how it works take a look at our [SDK Primer](docs/zt_sdk_primer.md)
 
 ## APIs
 
 **Hook/Intercept**
 - Uses dynamic loading of our library to allow function interposition or "hooking" to re-implement traditional socket API functions like `socket()`, `connect()`, `bind()`, etc.
 
-**SOCKS5 Proxy**
-- Provides an integrated SOCKS5 server alongside the ZeroTier service to proxy connections from an application to resources on a ZeroTier network. For instance, a developer which has built an iOS app using the NSStreams API could add ZeroTier to their application and simply use the SOCKS5 support build into NSStreams to reach resources on their network. An Android developer could do the same using the SOCKS5 support provided in the `Socket` API.
-
 **Direct Call**
-- Directly call the `zt_` API specified in [SDK.h](src/SDK.h). For this to work, just use one of the provided headers that specify the interface for your system/architecture and then either dynamically-load our library into your app or compile it right in. 
+- Directly call the `zt_` API specified in [src/sdk.h](src/SDK.h). For this to work, just use one of the provided headers that specify the interface for your system/architecture and then either dynamically-load our library into your app or statically-link it at compile-time.
 
 
 ***
@@ -82,3 +94,7 @@ We've designed a background tap service that pairs the ZeroTier protocol with sw
 
 ***
 ![Image](docs/img/api_diagram.png)
+
+
+More discussion can be found in our [original blog announcement](https://www.zerotier.com/blog/?p=490) and [the SDK product page](https://www.zerotier.com/product-netcon.shtml).
+If you have any feature or support requests, be sure to let us know [here](https://www.zerotier.com/community/)!

docs/limitations.md

@@ -1,13 +0,0 @@
-Notes / Limitations
-====
-
-## Limitations and Compatibility
-
-The beta version of the SDK **only supports IPv4**. There is no IPv6 support and no support for ICMP (or RAW sockets). That means network-containerizing *ping* won't work.
-
-The virtual TCP/IP stack will respond to *incoming* ICMP ECHO requests, which means that you can ping it from another host on the same ZeroTier virtual network. This is useful for testing.
-
-
-#### Controlling traffic
-
-**Network Containers are currently all or nothing.** If engaged, the intercept library intercepts all network I/O calls and redirects them through the new path. A network-containerized application cannot communicate over the regular network connection of its host or container or with anything else except other hosts on its ZeroTier virtual LAN. Support for optional "fall-through" to the host IP stack for outgoing connections outside the virtual network and for gateway routes within the virtual network is planned. (It will be optional since in some cases total network isolation might be considered a nice security feature.)

docs/osx.md

@@ -5,25 +5,13 @@ Welcome!
 
 Imagine a flat, encrypted, no-configuration LAN for all of the instances of your OSX app. 
 
-This short tutorial will show you how to enable ZeroTier functionality for your OSX app with little to no code modification. Check out our [ZeroTier SDK](https://www.zerotier.com/blog) page for more info on how the integration works.
-
 ***
 
-## Via Traditional Linking (Everything bundled)
+## Via Traditional Linking (Service and Intercept)
 
- - Use this if you'd like everything included in a single easy-to-use library.
+ - This will allow the interception of traditional socket API calls such as `socket()`, `connect()`, `bind()`, etc.
 
-```
+Build against our library:
-make osx_shared_lib`
-g++ app.cpp -o app libztosx.so
-./app
-```
-
-## Via Traditional Linking (Service+Intercept model)
-
- - Use this model if you'd like multiple applications to talk to the same ZeroTierSDK service instance. Often the *intercept-model* is used when you don't have access to the source of an app and you'd like to re-direct its network calls.
-
-Example:
 
     gcc app.c -o app libztintercept.so
     export ZT_NC_NETWORK=/tmp/sdk-test-home/nc_8056c2e21c000001
@@ -87,4 +75,4 @@ Or, establish a connection:
 
 **Alternative APIs**
 
-CLick [here](../../../../docs/api_discussion.md) to learn more about alternative APIs such as the Intercept and SOCKS5 Proxy.
+Click [here](../../../../docs/api_discussion.md) to learn more about alternative APIs such as the Intercept and SOCKS5 Proxy.

docs/tests.md

@@ -1,5 +1,5 @@
 Testing
-====
+======
 
 To build the API unit tests:
  - `make tests`

docs/zt_sdk_primer.md

@@ -1,69 +0,0 @@
-# ZeroTier SDK Primer
-
-True P2P injected right into your app with little to no code changes! A ZeroTier-enabled app. 
-(formerly known as Network Containers)
-
-The SDK couples the ZeroTier core Ethernet virtualization engine with a user-space TCP/IP stack and a carefully-crafted API which intercepts and re-directs network API calls to our service. This allows servers and applications to be used without modification or recompilation. It can be used to run services on virtual networks without elevated privileges, special configuration of the physical host, kernel support, or any other application specific configuration. It's ideal for [containerized applications](../integrations/docker), [games](../integrations/Unity3D), and [desktop/mobile apps](../integrations).
-
-Your only responsibility is to pick an API appropriate for your app's design. Accessing resources (potentially other instances of your app) on the virtual network will work exactly as it would on a real LAN. The service supports both TCP and UDP. The ZeroTier SDK now works on both *x64* and *ARM* architectures. We've tested a beta version for *iOS*, *Android*, *Linux*, and *Mac OS*
-
-The general idea is this:
-	1) Your application starts.
-	2) The API and ZeroTier service initializes inside a separate thread of your app.
-	3) Your app can now reach anything on your virtual network via normal network calls.
-
-It's as simple as that!
-
-***
-
-More discussion can be found in our [original blog announcement](https://www.zerotier.com/blog/?p=490) and [the SDK product page](https://www.zerotier.com/product-netcon.shtml).
-If you have any feature or support requests, be sure to let us know [here](https://www.zerotier.com/community/)!
-
-Combine this functionality with the network/device management capabilities of [ZeroTier Central](https://my.zerotier.com) and its associated [API](https://my.zerotier.com/help/api) and we've hopefully created a simple and reliable way for you to flatten and reduce the complexity of your app's networking layer.
-
-In addition, since this connectivity is mediated over the ZeroTier protocol, you get a free layer of encryption by default. That being said, we still suggest you add your own security layer to match your responsibilities.
-
-***
-## What's happening under the hood?
-
-Suppose you write an application that uses sockets to make a connection to some remote server. Normally in order to access resources on a virtual network you'll need to develop some sort of networking layer internally within the app or employ some external software and establish a system-wide connection. Here's an example of how network flow would be handled in this case:
-![Image](img/app_flow.png)
-
-As you can see, your app's logic somehow interacts with a networking layer, the calls then would go to the system and eventually interact with the kernel's network stack. 
-
-Now suppose you've linked ZeroTier into your app, since our API will intercept the network calls we can actually define new behaviour for them. Here's an example of how network flow would be handled for a ZeroTier-enabled app:
-![Image](img/zt_app_flow.png)
-
-When your applcation attempts to establish a connection over a socket the following happens:
-
-- application calls `socket()`
-- our library's `zt_socket()` is executed instead
--  library establishes an `AF_LOCAL` socket connection with the service (this is used to orchestrate communication between the library and the ZeroTier service)
-- an `RPC_SOCKET` message is sent to the ZeroTier tap service
-- the tap service receives the `RPC_SOCKET` message and requests the allocation of a new "connection" object representing the new "socket" from lwIP
-- If the user-space network stack grants the tap service the new connection object, the tap service then repurposes the socket used for the RPC message and returns its file descriptor to your application for it to use as the new socket.
-
-From your application's perspective nothing out of the ordinary has happened. It called `socket()`, and got a file descriptor back.
-
-#### You might be wondering some of the following:
-- **What would happen if you attempted to create a socket of the `AF_LOCAL` variety?**
-  - Our library will ignore it and pass the call to the system's normal `socket()` implementation since it isn't meant to leave the machine.
-- **What would happen if you performed a `getsockopt()` for the family/domain of an `AF_INET` socket you requested?** 
-  - You'd expect this should return `AF_LOCAL` since we repurposed the unix-domain socket, right? Nope. We've got a special implementation of `getsockopt()` which will detect whether that socket is handled under the ZeroTier tap service and if it is, it'll lie to you about the socket domain/family and report `AF_INET`. 
-
-We've got a [special implementation](../src/sockets.c) for most of the socket API functions: `zt_setsockopt(), zt_getsockopt(),zt_socket(),zt_connect(),zt_bind(),zt_accept4(),zt_accept(),zt_listen(),zt_close(),
-zt_getsockname()`. Each type of API is implemented in terms of this set of core functions and has the ability to determine whether the call should be directed to the system or the ZeroTier tap service.
-
-## Embedded Applications / IoT
-![Image](img/archs.png)
-
-We foresee the largest application of the ZeroTier SDK to be embedded devices that require lightweight, efficient and reliable networking layers that are also secure and effortless to provision. We've specifically engineered the core service and the API library to be as lightweight and portable as possible. We'd like to see people retake control of their data and security by skipping the the "cloud" without adding complexity.
-
-![Image](img/zt_why.png)
-
-## Games
-We think this solution is well suited for low-latency multiplayer games where reliability and ease of use are important.
-
-The ZeroTier protocol is inherently P2P and only falls back to a relay in the event that your direct link is interrupted. It's in our best interest to automatically find the quickest route for your data and to *not* handle your data. This has the obvious benefits of reduced latency for your game, but also provides you better security and control of your data and reduces our costs. It seems non-sensical to do it any other way. ZeroTier is not a "cloud" that you send all of your data to.
-
-We've just begun work on a native [Unity 3D](https://unity3d.com/) plugin to enable your Unity app to communicate over ZeroTier networks. You can check out our BETA [here](../integrations/Unity3D)

integrations/apple/example_app/OSX/README.md

@@ -5,25 +5,13 @@ Welcome!
 
 Imagine a flat, encrypted, no-configuration LAN for all of the instances of your OSX app. 
 
-This short tutorial will show you how to enable ZeroTier functionality for your OSX app with little to no code modification. Check out our [ZeroTier SDK](https://www.zerotier.com/blog) page for more info on how the integration works.
-
 ***
 
-## Via Traditional Linking (Everything bundled)
+## Via Traditional Linking (Service and Intercept)
 
- - Use this if you'd like everything included in a single easy-to-use library.
+ - This will allow the interception of traditional socket API calls such as `socket()`, `connect()`, `bind()`, etc.
 
-```
+Build against our library:
-make osx_shared_lib`
-g++ app.cpp -o app libztosx.so
-./app
-```
-
-## Via Traditional Linking (Service+Intercept model)
-
- - Use this model if you'd like multiple applications to talk to the same ZeroTierSDK service instance. Often the *intercept-model* is used when you don't have access to the source of an app and you'd like to re-direct its network calls.
-
-Example:
 
     gcc app.c -o app libztintercept.so
     export ZT_NC_NETWORK=/tmp/sdk-test-home/nc_8056c2e21c000001
@@ -87,4 +75,4 @@ Or, establish a connection:
 
 **Alternative APIs**
 
-CLick [here](../../../../docs/api_discussion.md) to learn more about alternative APIs such as the Intercept and SOCKS5 Proxy.
+Click [here](../../../../docs/api_discussion.md) to learn more about alternative APIs such as the Intercept and SOCKS5 Proxy.

make-mac.mk

@@ -350,10 +350,12 @@ update_examples:
 # For authors
 # Copies documentation to all of the relevant directories to make viewing in the repo a little easier
 update_docs:
-	cp docs/android_zt_sdk.md integrations/android/README.md
+	cp docs/intro.md README.md
-	cp docs/ios_zt_sdk.md integrations/apple/example_app/iOS/README.md
+	cp docs/network_stacks.md src/stack_drivers/README.md
-	cp docs/osx_zt_sdk.md integrations/apple/example_app/OSX/README.md
 	cp docs/integrations.md integrations/README.md
-	cp docs/zt_sdk_intro.md README.md
+	cp docs/osx.md integrations/apple/example_app/OSX/README.md
-	cp docs/docker_linux_zt_sdk.md integrations/docker/README.md
+	cp docs/ios.md integrations/apple/example_app/iOS/README.md
-	cp docs/osx_unity3d_zt_sdk.md integrations/Unity3D/README.md
+	cp docs/docker.md integrations/docker/README.md
+	cp docs/android.md integrations/android/README.md
+	cp docs/osx_unity3d.md integrations/Unity3D/README.md
+	cp docs/tests.md tests/README.md

src/README.md

@@ -4,3 +4,5 @@ Source Directory Structure
 `wrappers` - Example bindings of the ZeroTierSDK Sockets API to your favorite native languages
 
 `stack_drivers` - Drivers to mate various network stacks to the ZeroTier tap interface
+
+See [here](../docs/technical.md) for a technical discussion on this all works.

src/stack_drivers/README.md

@@ -1,4 +1,25 @@
-Stack Drivers
+Hot-Swappable Network Stacks!
 ====
 
-These files contain code to load, initialize, and interface network stacks to the ZeroTier ethernet tap service.
+We've now enabled the ability for users to build the ZeroTier SDK with different network stacks with the mere flip of a compiler flag as well as running different stacks concurrently! This is perfect for embedded developers which may need a smaller code footprint and would like to use their own smaller or more specialized network stacks.
+
+`SDK_LWIP=1` and `SDK_PICOTCP=1` will enable the lwIP and picoTCP network stacks respectively.
+
+Currently our *lwIP* stack driver supports IPV4 and limited IPV6, whereas our *picoTCP* stack driver supports both IPV4 and IPV6 with no known issues.
+
+To enable specific protocol versions use `SDK_IPV4=1` and `SDK_IPV6=1` in conjunction with the above stack selection flags.
+
+Also, to enable debug for the SDK use `SDK_DEBUG=1`, to enable debug for the *lwIP* stack use `SDK_LWIP_DEBUG=1`. 
+
+## Integrating Your Own Custom Stack
+
+If you don't know why this section exists, then I suggest turning back now. This is not for you. Otherwise, let's get on with things, here's how you can integrate your own custom network stack if for some reason lwIP or picoTCP aren't cutting it for you:
+
+Investigate the structure of `src/tap.cpp`, this file contains calls to functions implemented in the stack driver code (located in `src/stack_drivers`).
+
+Each stack is different but generally you'll need to provide:
+ - An initialization function to configure and bring up the stack's `interface` (or similar).
+ - An I/O polling loop section where you'll execute your timer calls, and check for inbound and outbound frames.
+ - A low-level input and output function to handle feeding ethernet frames into and out of the stack in its own unique way.
+ - Calls to your stack's API which roughly correspond with `handleRead()`, `handleWrite()`, `handleSocket()`, `handleConnect()`, etc
+ - In those calls you'll need to handle the creation, management, and destruction of your stack's "connection" objects, whatever that may be.

tests/README.md

@@ -0,0 +1,9 @@
+Testing
+======
+
+To build the API unit tests:
+ - `make tests`
+
+All necessary binaries and scripts will be built and copied into `build/tests`.
+
+Running `build/tests/test.sh` will execute the automatic API unit tests.

tests/api_test/zt_tcpserver4.c

@@ -6,9 +6,6 @@
 #include <arpa/inet.h> 
 #include <unistd.h>  
  
-#include "sdk.h"
-//
- 
 int atoi(const char *str);
 
 int main(int argc , char *argv[])