|
24 | 24 | /** |
25 | 25 | * # CategorySDLNet |
26 | 26 | * |
27 | | - * Header file for SDL_net library |
28 | | - * |
29 | | - * A simple library to help with networking. |
| 27 | + * SDL_net is a simple library to help with networking. |
| 28 | + * |
| 29 | + * In current times, it's a relatively thin layer over system-level APIs like |
| 30 | + * BSD Sockets or WinSock. It's primary strength is in making those interfaces |
| 31 | + * less complicated to use, and handling several unexpected corner cases, so |
| 32 | + * the app doesn't have to. |
| 33 | + * |
| 34 | + * Some design philosophies of SDL_net: |
| 35 | + * |
| 36 | + * - Nothing is blocking (but you can explicitly wait on things if you want). |
| 37 | + * - Addressing is abstract so you don't have to worry about specific networks |
| 38 | + * and their specific protocols. |
| 39 | + * - Simple is better than hard, and not necessarily less powerful either. |
| 40 | + * |
| 41 | + * There are several pieces to this library, and most apps won't use them all, |
| 42 | + * but rather choose the portion that's relevant to their needs. |
| 43 | + * |
| 44 | + * All apps will call NET_Init() on startup and NET_Quit() on shutdown. |
| 45 | + * |
| 46 | + * The cornerstone of the library is the NET_Address object. This is what |
| 47 | + * manages the details of how to reach another computer on the network, and |
| 48 | + * what network protocol to use to get there. You'll need a NET_Address to |
| 49 | + * talk over the network. If you need to convert a hostname (such as |
| 50 | + * "google.com" or "libsdl.org") into a NET_Address, you can call |
| 51 | + * NET_ResolveHostname(), which will do the appropriate DNS queries on a |
| 52 | + * background thread. Once these are ready, you can use the NET_Address to |
| 53 | + * connect to these hosts over the Internet. |
| 54 | + * |
| 55 | + * Something that initiates a connection to a remote system is called a |
| 56 | + * "client," connecting to a "server." To establish a connection, use |
| 57 | + * the NET_Address you resolved with NET_CreateClient(). Once the connection |
| 58 | + * is established (a non-blocking operation), you'll have a NET_StreamSocket |
| 59 | + * object that can send and receive data over the connection, using |
| 60 | + * NET_WriteToStreamSocket() and NET_ReadFromStreamSocket(). |
| 61 | + * |
| 62 | + * To instead be a server, that clients connect to, call |
| 63 | + * NET_CreateServer() to get a NET_Server object. All a NET_Server does is |
| 64 | + * allow you to accept connections from clients, turning them into |
| 65 | + * NET_StreamSockets, where you can read and write from the opposite side of |
| 66 | + * the connection from a given client. |
| 67 | + * |
| 68 | + * These things are, underneath this API, TCP connections, which means you can |
| 69 | + * use a client or server to talk to something that _isn't_ using SDL_net at |
| 70 | + * all. |
| 71 | + * |
| 72 | + * Clients and servers deal with "stream sockets," a reliable stream of bytes. |
| 73 | + * There are tradeoffs to using these, especially in poor network conditions. |
| 74 | + * Another option is to use "datagram sockets," which map to UDP packet |
| 75 | + * transmission. With datagrams, everyone involved can send small packets of |
| 76 | + * data that may arrive in any order, or not at all, but transmission |
| 77 | + * can carry on if a packet is lost, each packet is clearly separated |
| 78 | + * from every other, and communication can happen in a peer-to-peer model |
| 79 | + * instead of client-server: while datagrams can be more complex, these _are_ |
| 80 | + * useful properties not avaiable to stream sockets. |
| 81 | + * NET_CreateDatagramSocket() is used to prepare for datagram communication, |
| 82 | + * then NET_SendDatagram() and NET_ReceiveDatagram() transmit packets. |
| 83 | + * |
| 84 | + * As previously mentioned, SDL_net's API is "non-blocking" (asynchronous). |
| 85 | + * Any network operation might take time, but SDL_net's APIs will not wait |
| 86 | + * until they complete. Any operation will return immediately, with options |
| 87 | + * to check if the operation has completed later. Generally this is what |
| 88 | + * a video game needs, but there are times where it makes sense to pause |
| 89 | + * until an operation completes; in a background thread this might make |
| 90 | + * sense, as it could simplify the code dramatically. |
| 91 | + * |
| 92 | + * The functions that block until an operation completes: |
| 93 | + * |
| 94 | + * - NET_WaitUntilConnected |
| 95 | + * - NET_WaitUntilInputAvailable |
| 96 | + * - NET_WaitUntilResolved |
| 97 | + * - NET_WaitUntilStreamSocketDrained |
| 98 | + * |
| 99 | + * All of these functions offer a timeout, which allow for a maximum wait |
| 100 | + * time, an immediate non-blocking query, or an infinite wait. |
| 101 | + * |
| 102 | + * Finally, SDL_net offers a way to simulate network problems, to test the |
| 103 | + * always-less-than-ideal conditions in the real world. One can |
| 104 | + * programmatically make the app behave like it's on a flakey wifi connection |
| 105 | + * even if it's running wired directly to a gigabit fiber line. The functions: |
| 106 | + * |
| 107 | + * - NET_SimulateAddressResolutionLoss |
| 108 | + * - NET_SimulateStreamPacketLoss |
| 109 | + * - NET_SimulateDatagramPacketLoss |
30 | 110 | */ |
31 | 111 |
|
32 | 112 | #ifndef SDL_NET_H_ |
|
0 commit comments