So You Want to Build a Language VM - Part 24 - SSH Server: Part 2

Most network communication between computers utilize TCP (transmission control protocol) or UDP (user datagram protocol). Higher-level abstractions build on top of these. HTTP, for example, uses TCP underneath. This is a complex topic, so for now, remember these two points:

TCP is best for our needs.

If a server is on a network, it is using an interface. This is the piece of the hardware that the network cable plugs into, and its abstraction in the operating system. These interfaces have an IP Address, which unique identifies that server on the network. They look like 192.168.1.10. Each of the 4 fields can range from 0 to 255.

If you are on a Mac or Linux computer, you can see your interfaces by typing ifconfig -a. An example is:

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether 8c:85:90:7a:53:04
    inet6 fe80::462:3eb0:435b:7753%en0 prefixlen 64 secured scopeid 0x8
    inet 192.168.1.34 netmask 0xffffff00 broadcast 192.168.1.255
    nd6 options=201<PERFORMNUD,DAD>
    media: autoselect
    status: active

The interface name is en0, and its IP Address is 192.168.1.34.

Linux servers have a range of ports that programs can bind to. These range from 1 to 65535. Think of these as phone extensions. Ports between 1 and 1024 are reserved for use by the OS, and only the root user can bind to those. Ports above that can be used by your program.

A program can bind to a combination of and interface and port. For example, HTTP servers bind to port 80. HTTPS binds to port 443. Once a program has done that, external programs can reach it across the network. When you send a request to a different machine across a network, the destination IP and port number are included. The OS then knows how to route that message to the programs listening on that interface and port.

Let’s look at what is in client.rs:

use std::io::{BufRead, Write, Read};
use std::io::{BufReader, BufWriter};
use std::net::TcpStream;
use std::sync::mpsc::{Sender, Receiver};
use std::sync::{mpsc};
use std::thread;
use repl;

pub struct Client {
    reader: BufReader<TcpStream>,
    writer: BufWriter<TcpStream>,
    raw_stream: TcpStream,
    repl: repl::REPL,
}

Each of our clients has three copies of the same stream we saw earlier in the server, as well as their own REPL. You’re probably wondering why we copy the stream. Its so we can wrap them in Rust’s BufReader and BufWriter, which allows us to send and receive data at a higher abstraction level than bytes. The raw_stream is there so that we can create the other two. That will make sense in a minute, I promise. =)

Let’s look at the implementation:

impl Client {
    pub fn new(stream: TcpStream) -> Client {
        // TODO: Handle this better
        let reader = stream.try_clone().unwrap();
        let writer = stream.try_clone().unwrap();
        let mut repl = repl::REPL::new();

        Client {
            reader: BufReader::new(reader),
            writer: BufWriter::new(writer),
            raw_stream: stream,
            repl: repl
        }
    }
        // more functions...
    }

Because we need a reader and writer, we use the stream’s ability to clone to create the additional connections. This would be cleaner if Rust had self-referential structs (https://internals.rust-lang.org/t/improving-self-referential-structs/4808), but it doesn’t yet. The raw stream is kept around in case we need more clones for some reason in the future.

There’s a few more functions in client.rs:

fn w(&mut self, msg: &str) -> bool {
    match self.writer.write_all(msg.as_bytes()) {
        Ok(_) => {
            match self.writer.flush() {
                Ok(_) => {
                    true
                }
                Err(e) => {
                    println!("Error flushing to client: {}", e);
                    false
                }
            }
        }
        Err(e) => {
            println!("Error writing to client: {}", e);
            false
        }
    }
}

This is a general write function. It takes any string, converts it to bytes, and uses our BufWriter<TcpStream> to send it to the client. We call flush to make sure it gets sent, instead of hanging around for some amount of time.

Next up, we have:

fn write_prompt(&mut self) {
    self.w(repl::PROMPT);
}

There’s two more functions in the Client struct, but we’re going to hop over to the repl module and look at some changes there first to give context. Open up src/repl/mod.rs. You’ll note the addition of some static strings:

These are just for convenience, so we use them in other modules.

In the REPL struct, we have added two things:

pub struct REPL {
    command_buffer: Vec<String>,
    vm: VM,
    asm: Assembler,
    scheduler: Scheduler,
    pub tx_pipe: Option<Box<Sender<String>>>,
    pub rx_pipe: Option<Box<Receiver<String>>>
}

See tx_pipe and rx_pipe? Those are being created in the constructor now:

I know that’s a lot of changes to the REPL to absorb, so here is a neatly itemized list:

The last two functions we are going to look at are:

When run is called, it calls recv_loop. This takes the rx_pipe from the Client’s REPL, spawns a thread, and just continually listens for input on it. When input is found (the REPL has sent something), we send it to the client.

The rest of the run function is printing the banner and then entering an infinite loop to listen for commands from the remote client.