You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
//### Connect the simulation to the 'real world' outside Internet
4
+
5
+
6
+
This example is similar to `A03_real_world`
7
+
8
+
A real-world AS included in the emulation
9
+
will collect the real network prefixes from the real Internet,
10
+
and announce them inside the emulator. Packets reaching this AS
11
+
will exit the emulator and be routed to the real destination.
12
+
Responses from the outside will come back to this real-world AS
13
+
and be routed to the final destination in the emulator.
14
+
15
+
16
+
17
+
The DevelopmentService prepares a node for [Remote Development with VSCode](https://code.visualstudio.com/docs/remote/remote-overview).
18
+
It installs the VSCode Remote Server on the Node during the docker image build, which allows to ssh into the running container later i.e. to debug software.
19
+
20
+
As of now the primary anticipated use of the seed-emulator has been the deployment of fully developed applications into an emulated szenario i.e. to observe its behaviour.
21
+
22
+
The DevService adapts the emulators primary paradigm of deploying fully develped applications into an emulated szenario,
23
+
to meet the need of developing i.e. P2P software to maturity in a distributed environment.
24
+
25
+
The DevService allows for each individual node that it is installed on, to specify one or more Git repositories that shall be checked out
26
+
(along with the desired filesystem path and branch) as well as the VSCode Extensions required for the projects software stack
27
+
(i.e. golang.Go for the SCION-proto implementation which is written in Go)
28
+
The DevService takes care to install the entirety of build and analysis tools that are needed for a given programming language at docker image build time (for Go this being i.e. the compiler, language server gopls, debugger delve) so that no annoying time delay arises once the emulator is running and you want to attach to a container.
29
+
Any specified Git repositories are checked out on its own separate docker volume, for the changes to persist between runs of the simulator in case one forgets to push.
30
+
31
+
Since software development requires a 'real Internet' connection of the container be it to git push/pull or fetch project dependencies for a build (i.e. go get, cargo build etc. )
32
+
This is achieved by promoting the nodes default gateway ( router node ) in the simulation into a 'RealWorldRouter' (which has access to the `000_svc` service network)
33
+
Use of a separate service network inhibits 'short-circuiting' the simulated network topology (i.e. any crosstalk past the intended network topo among nodes)
0 commit comments