edgynet

Help

Overview

We're building Edgynet as a training platform for network engineers. Currently the system is designed to give the appearance that you are interacting with 5 Linux® servers. They are not really Linux servers, just simulators. In the future we would hope to offer simulators for other types of network devices.

Any Feedback you can give us about the system, and about what you would like this system to be able to do, will be greatly appreciated.

Shell Commands

ping

Only a subset of the standard Linux ping options are supported. Use "ping -h" to see what's available.

Manpage for the real ping command (manpages.ubuntu.com): PING(8)

traceroute

Only a subset of the standard Linux traceroute options are supported. Use "traceroute -h" to see what's available.

Manpage for the real traceroute command (manpages.debian.net): TRACEROUTE(8)

nc (netcat)

Netcat can only be used with the UDP option (-u) since TCP has not yet been implemented in the Edgynet TCP/IP stack. "nc -h" will show what options are available.

Manpage for the real netcat command (manpages.debian.net): NC(1)

ifconfig

Should act more or less like the real ifconfig. Use "ifconfig -h" to get an idea of what's implemented.

Manpage for the real ifconfig command (manpages.debian.net): IFCONFIG(8)

route

Works fine for viewing/manipulating the routing table. Use "ifconfig -h" to see what functionality is available.

Manpage for the real route command (manpages.debian.net): ROUTE(8)

ip (iproute2)

Much of the functionality in the real ip command is available, but there is still quite a bit that needs to be implemented. Policy-based routing is included, but it hasn't really been tested yet, so watch out. Use "ip" or "ip help" to see what objects are available, and "ip <object> help" to see what's implemented for that object, eg:

ip route help
ip addr help

Manpage for the real iproute2 command set (manpages.debian.net): IP(8)

Configuration Options

Server Communication: Comet/HTTP or Java Applet?

You can switch the server communication method from using Comet/HTTP, to using TCP via a Java Applet, by clicking on the Preferences button on the Demo page and making your selection from there.

Comet/HTTP is the default method for communicating back with our demo server. You should stick with Comet unless you find that it's too slow. If typing into the shells feels sluggish, then you might want to consider giving the Java Applet a try.

We introduced the Java Applet to benefit folks connecting from outside of Europe (where our demo server resides) and for those who are connecting over high latency Internet connections (eg 3G connections).

In general, if you ping www.edgynet.com and you find that your round-trip time (RTT) is 60ms or less, then stick with Comet/HTTP. Realistically, this is only going to happen if you are:

  1. in Europe, or near by; and
  2. using a wire-based Internet connection (so no 3G, etc).

Comet/HTTP should still be bearable up to about 100ms, but above that it's likely to become increasingly uncomfortable to use.

Here's a selection of RTTs to our demo server from around the globe (thanks to just-ping.com):

Location Min Avg Max
Hong Kong, China 262.7 271.3 278.0
Sydney, Australia 305.1 305.6 307.3
New York, U.S.A. 104.7 109.4 111.9
London, United Kingdom 16.4 16.9 17.7
Madrid, Spain 38.0 39.6 48.4
Rio de Janeiro, Brazil 212.3 214.3 218.4
San Francisco, U.S.A. 178.0 178.2 178.5
Johannesburg, South Africa 443.4 512.3 622.0
Mumbai, India 170.2 171.9 174.5
Nagano, Japan 279.9 285.6 290.0
Dublin, Ireland 49.6 50.3 50.9
Moscow, Russia 58.4 58.7 59.4

Edgynet Stopwatch

If you'd like to get concrete timing results on how Comet/HTTP compares to the Java Applet from your location, check out our Edgynet Stopwatch project. It's a latency testing and graphing tool that will give you exactly the type of information you're looking for. You'll find it at:

http://stopwatch.edgynet.com

When using this tool, keep in mind that you are really only interested in the timings for 1-8 messages per second. A touch-typer (60 words per minute) will only generate up to 5 messages per second. Other messages in the background might push this up to about 8 messages per second. So, to get the most realistic results, you'll want to choose the DIY test and set it to start at "1" and end at "8". It should take about 10 mins for such a test to run.

Potential problems with the Java Applet

  • Could crash your browser!

    We strongly recommend that you use Suns Java Plugin version 1.6.10 or above.

    Using the IcedTea plugin is not recommended at the moment. We did get our system working with the IcedTea plugin with openjdk-6 + Firefox 3.0 on Ubuntu, but it was very slow - around 250ms RTT over 100Mbps network - and the plugin frequently locked up during testing.

  • This Applet won't work from behind a HTTP proxy.
  • Java defaults to IPv6 instead of IPv4, causing problems on some flavours of Linux.

    When this happens, your system basically appears to hang whenever you try to use Java. If you have Java installed, and you are not using IPv6, it's a good idea to configure Java to default to IPv4. If you're running a recent version of Java you should be able to do this through the Java Control Panel, as follows:

    First, to load the Java Control Panel application, open up a shell and type ControlPanel. It could take a few minutes - yes minutes - for the application to load. This is due to the very same problem that is affecting Applets. Okay, so once the Java Control Panel is loaded, you navigate to the "Java" tab and click on the "view" button for the Java Applet Runtime Settings. Click "Add" to add an entry and type the following in the "Runtime Parameters" field:

    -Djava.net.preferIPv4Stack=true

    Click OK. Then restart your browser, just to be sure.

Problems

Terminals don't accept input, or they stop accepting input

The first thing to check is to make sure that you don't have the demo page open in two different places (ie in two different browser tabs or windows). If you do, then you need to close one of them down. In the future we will fix this problem so that multiple demo pages can be open simultaneously.

If you're curious why this happens, it's because we're using Comet, and your browser is limiting itself to 2 HTTP connections per server, as specified in the HTTP 1.1 standard. There are work-arounds for this problem, we just haven't got around to implementing them yet! :-)

Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.