We’ve just released a new video in our Support Centre, which describes how to adjust firewall and router settings to use AIRShip:
It may be that you do not need to make any adjustments, if you are working with third parties who have already taken care of things at their end. If you are unsure, please check with someone acting as a Company Administrator for your Company, in the AIRShip portal to which you have access.
To accompany the release of AIRShip v2.3 on Monday 18th April we are commencing the release of a new series of AIRShip video tutorials, which explain how to install and use AIRShip. These are all available via our Support Centre.
Videos already released include:
- Making the switch from AIRShip v2.2 to v2.3
- Register to use AIRShip
- Install AIRShip (via portal login page)
We will announce releases of videos via our AIRShip Twitter feed.
AIRShip ships files between Locations. Locations are managed by our Shipping Agent application, installed on each computer involved in shipping. The Shipping Agents do the actual shipping, between the Locations they are managing.
In this situation the Locations are acting as Endpoints in the delivery chain. However, an AIRShip Location can also be set up as as a Transit Hub, which acts as an intermediary, providing a stepping stone for the delivery of files. The transitory files are stored encrypted on the Transit Hub, and are deleted when they have been delivered to the destination Endpoint Location. Using a Transit Hub is the best way to resolve the problem of a computer configured to use AIRShip not being able to receive inbound connections on port 4115 (the default port via which our software communicate). Transit Hubs can also act as edge devices, managing the flow of data in/out of a facility, and are also capable of bridging public/private networks (where this is desirable). We explain Transit Hubs in more detail in the Tech specs section of this website.
We host our own Transit Hubs on AWS instances. Most of these are not used constantly, so we usually turn them on and off manually, which is somewhat inconvenient. Therefore, we thought it would be helpful to develop the ability for AIRShip to turn on and off AWS instances automatically, so they can be turned on to carry out AIRShip Workflow Tasks, and turned off when these complete.
We are in the process of integrating this functionality into AIRShip, and aim to make it available in the first incremental release following our launch of AIRShip v2.3.