CS208 Introduction to Computer Systems
Wednesday, 8 March 2023

+ Questions

+ Friday: Exam questions followed by AMA

+ Networks
- Try these (dollar sign means "Unix prompt"):

    $ nc time-d-b.nist.gov 13

    $ host cs.carleton.edu
    
- Clients asking for service from servers

- nc/netcat: all-purpose client (or server) for studying this stuff

- Hosts: IP address & domain name

    $ host cs.carleton.edu
    cs.carleton.edu is an alias for blue.mathcs.carleton.edu.
    blue.mathcs.carleton.edu has address 137.22.5.8

- Ports: which server on that host do you want to talk to?
    cs.carleton.edu, port 80 or 443 or 22 or 5432

    $ nmap -sT -vv -Pn cs.carleton.edu

- Protocols: how do you ask a server for service?

- Super-simple protocol: just connect and say nothing

    client makes a connection
    server sends some protocol-specific data
    server closes the connection

Example: daytime protocol, port 13
    (https://www.rfc-editor.org/rfc/rfc867.txt)

    $ nc time-d-b.nist.gov 13

- Typical protocol: connect, then ask for something

    client makes a connection
    client sends request (formatted as specified in the protocol)
    server sends response (ditto)
    (continue back and forth until one side closes the connection...)

Example: the hypertext transfer protocol, port 80
    (https://www.rfc-editor.org/rfc/rfc9110)

    $ nc sandbox.jeffondich.com 80
    GET /index.html HTTP/1.1
    Host: sandbox.jeffondich.com
    [blank line]

- Want to write a C client or server? You need to create a "socket"

    sockets are open/close/read/write objects
    socket descriptors go in the file descriptor table, just like
        stdin, stdout, stderr, and open() or dup2() results
    both clients and servers can use them

- Socket workflow (server side)
    see prepare_to_accept_connections in tcp_utilities.c
    and main() in hello_server.c

    socket()                         [create socket]
    create an "address" struct       [struct sockaddr_in]
      contains IP address and port
    bind()                           [attach socket to sockaddr_in]
    listen()                         [say "this socket is a server"]
    accept()                         [returns when a connection request arrives]
    read, write, close               [like read/write/close with a file]

- Socket workflow (client side)
    see make_connection in tcp_utilities.c and main() in hello_client.c

    socket()                         [create socket]
    create a "remote address" struct [struct sockaddr_in]
      contains IP address and port
    connect()                        [says "this socket is a client; connect it to the address"]
    read, write, close               [like read/write/close with a file]

NOTE: The "in" in "sockaddr_in" stands for "internet protocols", not "input"

- What's new here?
    - clients and servers
    - TCP connections
    - IP addresses and domain names
    - TCP ports
    - sockets with bind, listen, accept, and connect
    - the slightly odd behavior of read()

- What's old?
    - fork and wait (hello_server_concurrent.c)
       pthread_create, etc. (your program)
    - read, write, close
    - command-line parsing
    - plundering Jeff's sample code

- Walk through the code

- Advice
    - keep your code modular
    - don't change my sample code any more than you have to
    - need tcp_utilities.h/.c
        gcc ... -o shouting_server shouting_server.c tcp_utilities.c

    - try this development plan
        - start with hello_server_concurrent.c
        - observe that hello_server_concurrent.c doesn't handle zombies
            properly. That's my fault, and I'll work it out with Mike.
            (Mostly, he'll just reboot mantis after finals.)
            I'll fix this before next term, but the fix is complex enough
            that I don't want to bother you with it.
        - say the phrase "Jeff told me I don't have to worry about zombies"
            out loud several times
        - keep the fork/wait structure for now
        - adjust process_request to do the thing you want it to do
        - test it with nc so you don't have to write your own client
        - [if you get this far, you'll get several points of
            partial credit; if you're running out of time, this is
            a great place to stop]
        - now that process_request is working, try switching
            from a fork-based architecture to a pthread_create-based
            architecture. This will involve moving some code around,
            but it won't involve a lot of new code.

+ What would come next if we had time?
- Virtual memory
- Architecture
- How malloc works
- More details on synchronization with
    semaphores, mutexes, and their friends