1. CSCI1600: Embedded and Real Time Software Lecture 22: Networking, IPC Steven Reiss, Fall 2015

2. 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?

3. 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

4. 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?

5. 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)

6. 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

7. 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

8. 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

9. 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

10. Pipes  Similar to message queues except  Handle varying sized messages  May be entirely byte oriented  May take for messages  Can work across processes if messages lack pointers  Can work across machines  But have to be wary of endian problems

11. 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

12. 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

13. Commonalities  Framing: putting messages together  Error detection  Flow control  Reliability and guarantees  Bus “arbitrarion” / MAC protocols

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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  Send the message  Close connection

26. Simple Server Communicator  Use arbitrary message format  Use arbitrary host/port for the server  Send and receive messages in that format

27. Homework  Read 12.1 – 12.2

28. 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

29. 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

30. MACs and Arbitration  Time based  Devices work out which uses the medium  Bus arbitration  MAC protocols

31. 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

32. 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

33. 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

34. 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

35. 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

36. Sample Code – Main Loop for ( ; ; ) { 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(); }

37. Sample Code: Minimal Server main() { 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 }