Project Assigned

The next phase of the project is to build a concurrent, network-accessible database. Here's the basic idea:

• Take your existing shared library -- change nothing
• Take your existing client program -- throw it away
• Replace that client program with a server that uses sockets to accept requests via the network
• Create a new shared library. It should expose the same functionality as your old one -- but should use sockets to communicate back to your server. You'll need to represent the name of the database differently, because the network address is likely to be part of the name. You might want to consider a URL-like representation: "ip:port/filepsec"
• Write a database client using your new shared library. This should demonstrate that it works
• Tackle concurreny -- use threads or select to make the server concurrent. Protect any "critical sections" (things that could get tangled by concurrency, such as linked lists, counters, &c) with semaphores, condition variables, or mutexes (see discussion from last class). If using select, you might not need to worry about this -- or you might need to look at System V IPC (lemme' know if you need help here)
• Develop a test application that slams your now concurrent database. Place it on a SMALL few servers and demonstrate that your project works.

Sockets

Today we covered Berkley sockets -- the most common API for application-level network programming. Most of this detail is in the Sockets PowerPoint (ppt) used during today's discussion.

But, I do want to emphasize:

• SOCK_DGRAM is implemented by the UDP protocol. It is an unreliable, best-effort protocol without protection from loss delay. It sends whole messages, one at a time.
  
  
• SOCK_STREAM is implemented by the TCP protocol. It is a reliable protocol. So, in the event of packet loss it will diligently resent in order to give the application access to a complete and properly ordered stream. It is stream ordered, so it work sort-of-like a file -- reads return the next n bytes, writes tack n bytes onto the receiver's stream. Of course, you can't see into the future (or the past).