1 / 11

Socket Models

Socket Models. Different ways to manage your connections. Agenda. Modes Blocking/Non-Blocking Models Blocking Select Variations Select WSAAsyncSelect WSAEventSelect Overlapped I/O I/O Completion Port. Socket Modes. To Block or Not to Block. Blocking Mode. The default

britanney-guzman
Download Presentation

Socket Models

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SocketModels Different ways to manage your connections

  2. Agenda • Modes • Blocking/Non-Blocking • Models • Blocking • Select Variations • Select • WSAAsyncSelect • WSAEventSelect • Overlapped I/O • I/O Completion Port

  3. Socket Modes To Block or Not to Block

  4. Blocking Mode • The default • Easy to implement • A call to send() or recv() only returns when calling conditions met.

  5. Non-Blocking • Must set with I/O control • Ioctlsocket(sock,FIONBIO,true); • Nothing blocks (i.e., send, recv, close,…) • Returns WSAEWOULDBLOCK if not immediately successful • Essentially turns into a polling model • You must handle spinning by sleeping • Only use in a non-thread environment

  6. Modes vs. Model • Modes can be used with any Model • Models cover several general issues • How you discover when a socket is ready • Has data (recv) • Has room for data (send) • How data is copied from Kernel to your buffer • Number of threads

  7. I/O Models Blocking Select Overlapped I/O Completion Port

  8. Blocking • Easy Implementation • X-Platform • No event notification to avoid blocking necessitates multiple threads. • 2 Threads for each socket else starve • Send thread • Receive thread • Poor scaling performance due to # of threads • Good enough for most game clients • Socket calls are blocking by default

  9. SelectWorking with multiple socketsTell me when you’re ready • select (…) • File Descriptor Sets (FD_SET) • Read: sockets to check for pending data • Write: sockets to check for writable • OOB: same as read for OOB data • Macros FD_CLR(), FD_ISSET(), FD_SET(), FD_ZERO() • Always clear and set your FD_SET prior to select (even if using same descriptors). • Limited to 64 sockets by winsock.h but can be overridden. • X-Platform • Additional limitations by O/S • Only checks state. Still need to process the data with blocking call which won’t block because you’ve just been told it’s ready. • WSAAsyncSelect (…) • Notified via window message • Windows only • WSAEventSelect (…) • Notified via Event Object i.e., a signal • Windows only • These methods provide asynchronous notification, not async data transfer as does overlapped model

  10. Overlapped I/OTell me when data is in my buffer. • Async data transfer • Scales very well • Max 64 sockets per thread • A little complexity overhead • All socket requests return immediately. • Process with event objects or completion routines. • Window NT based O/S only (NT, 2000, xp)

  11. I/O Completion Ports • Best Scalability • One thread per CPU • Unlimited sockets per thread • Complex setup • Uses overlapped I/O constructs • CreateIoCompletionPort ( … ) • One completion port per socket is created • GetQueuedCompletionStatus (…) • 1 thread per proc handles all status using this method in each thread

More Related