Notes on Adhoc routing and simulation support (and misc topics
such as REST, gRPC, and serialization)
last update 6/19/2020
This page is divided into several sections:
- CORE/EMANE
- Brief overview (mostly pointers to information) of ad hoc
wireless
- Brief overview of two related approaches to distributed
computing (REST, gRPC) and a separate overview of
serialization
TOPIC CORE/EMANE
The VM appliance that contains Ubuntu 18.04 with Core/EMANE
working is here (warning: large file):https://people.cs.clemson.edu/~jmarty/courses/VirtualBox/CoreVM-6-15-2020.ova
You can import this with Virtual Box.
But for now....
- pwd for account s2s is s2s
- To start
- sudo killall core-daemon
- sudo service networking restart
- sudo /etc/init.d/core-daemon start
- core-gui
- Once the gui starts, go to file and open
- jjmEx1.imn : a simple two node wired
example.
- jjmWiFiAPEx1.imn : a 5 node 802.11g infrastructure
example
- Click the green run arrow to start the emulation
- Select two nodes - one will run the client UDPEcho/V4
client, the other the server (or you can run
perfTool/V9 perfClient and perfServer)
- Double click the client node - a bash shell
should open. This is a docker container
representing the wireless station.
- Issue 'cp /home/s2s/tmp/setupCOREnode.sh .'
- ./setupCOREnode.sh
- cd ./devel/UDPEcho/V4
- make clean; make all;
- Do the same for the server node
- Unicast will work - I can't get broadcast
to work.
Core :
Emane:
Further discussion
Quite a bit of related Linux code available :
IETF RFCs:
Misc.
- Googles gRPC : This protocol is
NS3: -
Tips:
- On s2s, procedure to start core:
- First stop it- any should work
- sudo /etc/init.d/core-daemon stop
- sudo service core-daemon stop
- sudo killall core-daemon
- Then restart networking and start core
- sudo service networking restart
- sudo /etc/init.d/core-daemon start
- core-gui
- Source code:
- cd Downloads/emane/src/models/mac/ieee80211abg
Advanced
- vtysh
- cd /tmp/pycore.45247
- ls
- cd n1.conf
- cd var.run.quagga
- vtysh
- exit
- emaneevent-location --help
- cd var.run.quagga
- vi emane-nems
- vim state
- vi platform1.xml
- vi nu.log
Topic: Issues and questions
I am still trying to figure out the difference between our
s2s VM setup and one setup with a docker service
https://finmars.co.uk/blog/9-core-and-docker-together-at-last
Topic REST, gRPC and serialization
REST, which stands for REpresentational State Transfer, is not
well understood although it is widely used. It might be
referred to as an API or a protocol allowing a client and server
application to interact over a network using standard
HTTP. Actually, REST is an architectural concept first
introduced in a PhD
dissertation back in 2000. The basic idea is best
illustrated with an example. The web link,
http://dummy.restapiexample.com/api/v1/employees , is an open server
side REST API. A client would issue a correct HTTP GET
message that includes the link and will be returned whatever the
server side is programmed to return. A client can
be written in any language, it just needs to know how to
generate correct HTTP messages. The client also needs to know
something about the server side application - in particular the
format of the returned data. The concept of
serialization defines how application level abstract data or objects
that get sent to a peer over a network get laid out in a network
buffer that eventually gets transmitted in a frame. Two common
formats are XML and JASON. The example REST API returns
a result in JSON. Try the following on a Unix
system: 'wget
http://dummy.restapiexample.com/api/v1/employees'
The client would need to know how to deal with data returned in
JSON. In addition to established standard message data formats
such as XML or ASN.1, other serialization methods that are
commonly used in IoT include:
- JSON: this article provides a good introduction to
https://rapidapi.com/blog/api-glossary/json/
- Application Message Formats - The application would
define standard message formats. For example, the
DNS protocol used in TCP/IP networks, includes the message
format description (refer to RFC 5395).
- Google's Protocol Buffers (ProtoBuf
v3) : This is a dynamic approach requiring
your program to utilize libraries that transform program data
constructs into serialized byte strings that include codes
allowing the receiver to know how to deserialize the data.
Protobuf becomes tightly coupled to the application.
Google provides support for all major languages and platforms.
gRPC is another Google project that resurrects the original RPC such
that it can be used as an alternative to REST APIs. This
article nicely summarizes gRPC - https://medium.com/better-programming/understanding-grpc-60737b23e79e