A data transport refers to the protocol used when data travels through the internet to the eagle.io servers. Transports are grouped into two categories: client transports and server transports. Issues such as scheduling, batching, and recovering from unreliable communications are affected by which category of transport is used. This article will explain the differences between the two.
This is the list of transport types you can choose from when creating a data source:
This list does not indicate the category, so let's break it down:
Client transports
- Download from FTP site
- Download via HTTP
- Read from Amazon S3
- Read from Dropbox
When using any of the client transports, eagle.io acts as the client to read files from another location on the internet, such as your FTP server, a public website, or your S3 bucket.
Server transports
- Upload via HTTP
- Email to eagle.io
- SMS to eagle.io
- Publish to mqtt.eagle.io
- Upload to ftp.eagle.io
- Upload to sftp.eagle.io
When using any of the server transports, eagle.io acts as the server, waiting to receive data sent by a client, such as your MQTT client or your FTP client.
Considerations for data transmission: scheduling, batching, and retries
When using client transports, eagle.io (the client) is responsible for any batching, scheduling, failure detection and retries. For example, if we are reading files from your FTP server and there is a communications failure, we can retry later. If the file is large, we will break it into smaller batches and download them separately. And downloads can be scheduled via the data source configuration.
When using server style transports, your client software is responsible for any batching, scheduling, failure detection and retries. That is because eagle.io (the server) is not aware of any connections that fail to initiate, and we don't have the ability to reach out to your client and retry an upload which has failed. All the server can do is wait to receive what is sent by the client.
With the disadvantages stated above, why would you want to use server transports? It gives you a lot of control over when data transmission occurs, and this can be useful; for example, a low-power device might wake up for 5 minutes once per day to send data. And for devices which are not publicly addressable on the internet (because they are behind a NAT gateway for example), server transports are generally the only option.
Conclusion
When using a server transport, most of the troubleshooting steps are going to involve the client, because eagle.io (the server) does not know why it has not received data.
Special mention: Campbell Scientific loggers
Campbell loggers have not been mentioned because they fall into a special category; the connection could be initiated either by eagle.io, or (in special cases) by the logger. This requires TCP Callback, covered in a different article.