CSCI1600: Embedded and Real Time SoftwareLecture 22: Networking, IPC

Steven Reiss, Fall 2015

Interprocess Comunication

Multiple tasks need to communicate We’ve covered shared memory

Using synchronization where necessary

When is synchronization necessary?

What other means are there?

Semaphores

We saw semaphores as a synchronization mechanism Protect a synchronized region

Protect a set of resources

Protect a producer-consumer queue

They can also be used for communication When the amount of information is small

Flag to let another task run

Is This Sufficient?

Semaphores are low level and error-prone Getting communications and synchronization right

Can be tricky

Can lead to hard to find and replicate problems

Higher level abstractions can be easier to use And can be supported by a RT operating system

What abstractions are appropriate?

Mailboxes What it is

A synchronized holder for a single message

Operations create – initialize a mailbox structure

accept – takes in a message

pend – waits for a message

post – sends a message

Messages void * (arbitrary pointer)

Mailbox Implementation

Mutex for operations

Create: set up everything, empty mailbox

Accept: check if mailbox is empty, if not, emtpy it

Pend: Wait until the mailbox is non-empty

Put task on wait queue for mailbox

Then get message and return it

Conflicts can be FIFO, priority-based, random

Mailbox Implementation Post:

If queued tasks, find proper waiter and remove from queue

Insert message into mailbox

Let that task continue

Else if there already is a message, return error

Else save message and return

Note that all operations are synchronized appropriately

What mailboxes can’t do Multiple messages (but can prioritize)

Blocking on post

Message Queues

Similar to mailboxes

Differences More than one message at a time

Can be dynamic or fixed maximum sized

Block on send

At least optionally

Message Queue Implementation

What does this look like Synchronized producer consumer queue

Handling multiple readers and writers

What this doesn’t handle Variable sized messages

Communication without shared memory

Pipes

Similar to message queues except Handle varying sized messages

May be entirely byte oriented

May take <length,data> for messages

Can work across processes if messages lack pointers

Can work across machines But have to be wary of endian problems

Higher Level Abstractions

Imply higher level bugs Bugs are less likely to be synchronization related

Data-oriented problems to watch out for Using the wrong queue/pipe/mailbox

Misinterpreting the passed data

“Ownership” of passed pointers

Wanting to ignore duplicate messages

Wider Scale Communications

Might want to do more Communicate between processes

Communicate between devices (e.g. in a car)

Means for doing so Attached devices: point-to-point communication

Busses

Ethernet: MAC (Media Access Control), UDP

Ethernet: TCP, IP

Commonalities

Framing: putting messages together

Error detection

Flow control

Reliability and guarantees

Bus “arbitrarion” / MAC protocols

Internetworking Embedded web server interface

IP cameras, switches, …

Post information to a server Sensors, …

Data from network shares Music player, web radio

Act as browsible share (TiVo)

Home automation, VoIP, alarms

Internetworking UDP (covered in CSCI1680)

Not very different from interacting with a bus

Best effort delivery (no reliability guarantees, acks)

You manage retries, assembly/dissembly, congestion

Good for sensor updates, etc.

TCP/IP Similar to a IPC pipe

Adds reliability, byte stream interface

Internally manages retries, ordering, etc.

Web services, simple APIs

TCP/IP Sockets are like 2-way pipes

Both sides can read/write independently

Sockets are address by host-port

Connection to a socket Create socket on the server

Bind it to a known port (on the known host)

Do an accept on the socket

Create a socket on the client

Connect to know server socket (connect) operation

Server does accept on its socket

This yields a new socket bound to that client

TCP/IP Lightweight implementation exist (even for Arduino)

Library interface for lwIP (Light Weight IP) ip_input(pbuf,netif)

Takes an IP package and the network interface as args

Does TCP/IP processing for the packet

tcp_tmr()

Should be called every 100ms

Does all TCP timer-base processing such as retransmission

Event-based callbacks

This is not sockets, but it is TCP/IP

lwIP Basics

Initialization: tcp_init

Manage all TCP connections tcp_tmr()

Must be called every 250 milliseconds

sys_check_timeout()

Calls tcp_tmr and other network related timers

lwIP Server Connection

tcp_new : create a PCB for a new socket

tcp_bind : bind that socket to a port on this host

tcp_listen : listen for connections

tcp_accept : specify a callback to call Passed routine called when someone tries to connect

tcp_accepted : called from the routine to accept the connection

lwIP Client Connection

tcp_new : create new PCB (socket)

tcp_bind : bind the socket to target host/port

tcp_connect : establish the connection Provides callback function

Called when connected

Or if there is an error in the connection

lwIP Sending Data

tcp_sent : specify callback function Called when data acknowledged by remote host

tcp_sndbuf : get maximum data that can be sent

tcp_write : enqueues the data for write Can be via copy or in-place

tcp_output : forces data to be sent

lwIP Receiving Data

tcp_recv : specifies a callback function Function called when data is received

Or when there is an error (connection closed)

Calls tcp_recved to acknowledge the data

lwIP Other Functions

tcp_poll : handle idle connections

tcp_close : close a connnection

tcp_abort : forcibly close a connection

tcp_err : register an error handling callback

Simple Web Server Assuming the host IP is known

Create a server socket on port 80

Listen for connections

Read message from connection

Should be header + body

Simple message = header only

Decode header, branch on URL

Compute output page

Send reply on the connection

HTTP header + HTML body

Simple Web Communicator

To send periodic updates Put together a message

Simple HTTP header

URL using ?x=v1&y=v2 to encode data

Connect to <SERVER HOST:80>

Send the message

Close connection

Simple Server Communicator

Use arbitrary message format

Use arbitrary host/port for the server

Send and receive messages in that format

Homework

Read 12.1 – 12.2

Point-to-Point Framing Sentinals

Special bytes at beginning and end of message

Escaped when inside a packet

Length counts Encode length of the packets explicitly

Bit errors may introduce big mistages

Clock-based Each frame is t microseconds long

Keep clocks synchronized with transitions

Example: RS232 Serial Ports

Many variants exist, 2 wire is simplest

A byte is encoded as 0bbbbbbbb1 (10 bits per byte)

bbbbbbbb is LSB first

Leave TX asserted until next byte

Software flow control: XON, XOFF

Hardware flow control Two extra wires: RTS, CTS

MACs and Arbitration

Time based

Devices work out which uses the medium Bus arbitration

MAC protocols

What is a bus System lines

Includes clock and reset

Address and data 32 time mux lines for address and data

Interrupt and validate lines

Arbitration Not shared

Controlled by PCI bus arbiter

Error lines

PCI Bus Arbitrarion

Four interrupt lines, rotated per device

Level triggered interrupts Hard to miss

Hard to share

Shared 33.33Mhz clock 32 bit width => 133MB max transfer speed

PCI Bus Arbitration

Bus master holds the right to use the bus at any time

Different strategies can be used to assign the master Daisy chain (round robin) – each gets a turn

Independent requests

Each device has its own signal it can send to controller

Polling

Controller counts through all devices

Device raises a flag when it wants to communicate

Programmed I/O vs DMA CPU – MEMORY also has a bus

With address lines

With data lines

With control lines (IRQ, NMI, VMA, R/W, BUS, RESET)

Read/Write to memory

Sets address lines

Reads/writes using data lines

BUS, R/W lines indicate when to read/write

Enable lines on devices wired directly to appropriate memory

Based on high order lines and low order lines

Ethernet Framing Carrier sense multiple access with collision detection

If line is idle Send immediately with fixed max frame size

Wait 9.6 microseconds between back-to-back frames

If line is busy Wait until idle and transmit immediately

If collision occurs Jam for 32 bits, then stop transmitting

Delay (random exponential backoff) and try again

Sample Code – Main Loopfor ( ; ; ) {

if (poll_driver(netif) == PACKET_READY) {

pbuf = get_packet(netif);

ip_input(pbuf,netif);

}

if (clock() – last_time >= 100 * CLOCK_MS) {

tcp_tmr();

last_time = clock();

}

}

Sample Code: Minimal Servermain() {

struct tcp_pcb * pcb

tcp_tcb_new();

tcp_bind(pcb,NULL,80);

tcp_listen(pcb);

tcp_accept(pcb,http_accept,NULL);

/* main loop */

}

 

http_accept(void * arg,struct

tcp_pcb * pcb) {

tcp_recv(pcb,http_recv,NULL);

}

 

http_recv(void * arg,

struct tcp_pcb *pcb,struct pbuf * p) {

// do something with packet p

}