Updated documentation to reflect changes in remoting

This commit is contained in:
Endre Sándor Varga 2013-01-23 11:38:20 +01:00
parent a31d98340f
commit c4abbd95bd
11 changed files with 219 additions and 91 deletions

Binary file not shown.

Before

Width:  |  Height:  |  Size: 41 KiB

After

Width:  |  Height:  |  Size: 42 KiB

Before After
Before After

Binary file not shown.

Before

Width:  |  Height:  |  Size: 56 KiB

After

Width:  |  Height:  |  Size: 42 KiB

Before After
Before After

View file

@ -98,14 +98,14 @@ Each actor path has an address component, describing the protocol and location
by which the corresponding actor is reachable, followed by the names of the
actors in the hierarchy from the root up. Examples are::
"akka://my-sys/user/service-a/worker1" // purely local
"akka://my-sys@host.example.com:5678/user/service-b" // local or remote
"cluster://my-cluster/service-c" // clustered (Future Extension)
"akka://my-sys/user/service-a/worker1" // purely local
"akka.tcp://my-sys@host.example.com:5678/user/service-b" // remote
"cluster://my-cluster/service-c" // clustered (Future Extension)
Here, ``akka`` is the default remote protocol for the 2.0 release, and others
are pluggable. The interpretation of the host and port part (i.e.
``serv.example.com:5678`` in the example) depends on the transport mechanism
used, but it must abide by the URI structural rules.
Here, ``akka.tcp`` is the default remote transport for the 2.2 release; other transports
are pluggable. A remote host using UDP would be accessible by using ``akka.udp``.
The interpretation of the host and port part (i.e.``serv.example.com:5678`` in the example)
depends on the transport mechanism used, but it must abide by the URI structural rules.
Logical Actor Paths
^^^^^^^^^^^^^^^^^^^