Leaked source code of windows server 2003
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

87 lines
3.4 KiB

  1. Simple IP samples.
  2. -----------------
  3. server.c:
  4. ----------
  5. This is a very simple-minded TCP/UDP server. It listens on a specified port
  6. for client connections. When a client connects, the server receives data
  7. and echoes it back to the client. For connection orientated protocols (TCP),
  8. the server will continue to receive and echo data until the client indicates
  9. that it is done sending. For connectionless protocols (UDP), each datagram
  10. is echoed individually.
  11. Usage:
  12. server -f <family> -t <transport> -p <port> -a <address>
  13. Where,
  14. Family is one of PF_INET, PF_INET6 or PF_UNSPEC.
  15. Protocol is either TCP or UDP.
  16. Port is the port number to listen on.
  17. Address is the IP address to bind to (typically used on multihomed
  18. machines to restrict reception to a particular network interface
  19. instead of allowing connections on any of the server's addresses).
  20. In the case where both a protocol family and an address are specified, the
  21. address must be a valid address in that protocol family.
  22. By default the protocol family is left unspecified (PF_UNSPEC), which means
  23. that the server will accept incoming connections using any supported protocol
  24. family. It does this by creating multiple server sockets, one per family.
  25. Note:
  26. ----
  27. There are differences in the way TCP and UDP "servers" can be written. For
  28. TCP, the paradigm of bind(), listen() and accept() is widely implemented.
  29. For UDP, however, there are two things to consider:
  30. 1. listen() or accept() do not work on a UDP socket. These are APIs
  31. that are oriented towards connection establishment, and are not applicable
  32. to datagram protocols. To implement a UDP server, a process only needs to
  33. do recvfrom() on the socket that is bound to a well-known port. Clients
  34. will send datagrams to this port, and the server can process these.
  35. 2. Since there is no connection esablished, the server must treat each
  36. datagram separately.
  37. client.c
  38. ---------
  39. A simple TCP/UDP client application. It connects to a specified IP address and
  40. port and sends a small message. It can send only one message, or loop for a
  41. specified number of iterations, sending data to the server and receiving a
  42. response.
  43. Usage:
  44. client -s <server> -f <family> -t <transport> -p <port> -b <bytes> -n <num>
  45. Where,
  46. Server is a server name or IP address.
  47. Family is one of PF_INET, PF_INET6 or PF_UNSPEC.
  48. Protocol is either TCP or UDP.
  49. Port is the port number to listen on.
  50. Bytes is the number of extra data bytes to add to each message.
  51. Num specifies how many messages to send.
  52. '-n' without any arguments will cause the client to send & receive messages
  53. until interrupted by Ctrl-C.
  54. Since the protocol family is left unspecified by default, the protcol family
  55. which is used will be that of the address to which the server name resolves.
  56. If a server name resolves into multiple addresses, the client will try them
  57. sequentially until it finds one to which it can connect.
  58. Note:
  59. ----
  60. As explained for server.c, there is no concept of a connection in UDP
  61. communications. However, we can use connect() on a UDP socket. This
  62. establishes the remote (IPaddr, port) to used when sending a datagram.
  63. Thus, we can use send() instead of sendto() on this socket.
  64. This makes the code nearly identical for UDP and TCP sockets. However, it
  65. must be realized that this is still connectionless datagram traffic for
  66. UDP sockets, and must be treated as such.