One of the most involved changes we made in Octopus Deploy 2.0 is the introduction of polling mode for Tentacles. You can read more about what polling mode is, and how to set up a Tentacle in polling mode, in the documentation:
The advantage to polling mode is that you don't need to make any firewall changes on the Tentacle side; you only need to allow access to a port on the Octopus server.
While some deployment products always work in "agent pulls" mode - the agents need direct communication with the central deployment server. Others work in "agent listens" mode. Octopus can now work in either mode.
As you can imagine, this involved some large changes internally. In 1.0, whenever Octopus needed to tell Tentacle to do something, it would just invoke an operation and wait for a result. But when Tentacle is polling, that can't work. Instead, we (and by we, I mean Nick) built a custom communication stack based on messages. Octopus or Tentacle can queue messages destined for the other, and the communication stack takes care of transferring the messages when a connection is established.
The new communication stack uses SSL with client certificates to perform the encryption, so it's just as secure no matter which service is listening and which is polling (the same two-way trust model is still in effect).
