HP Rp7410 BSD Sockets Interface Programmer's Guide - Page 170

Adding a Server Process to the Internet Daemon

Page 170 highlights

Programming Hints Adding a Server Process to the Internet Daemon * M A I N * * This is the actual server routine that the /etc/inetd forks to * handle each individual connection. Its purpose is to receive * the request packets from the remote client, process them, * and return the results to the client. * */ main() { char buf[10]; /* This example uses 10 byte messages. */ int len, lenl; /* Go into a loop, receiving requests from the remote * client. After the client has sent the last request, * it will do a shutdown for sending, which will cause * an end-of-file condition to appear on this end of the * connection. After all the client's requests have * been received, the next recv call will return zero * bytes, signaling an end-of-file condition. This is * how the server will know that no more requests will * follow, and the loop will be exited. */ while (len = recv(0, buf, 10, 0)) { if (len == -1) { exit (1); /* error from recv */ } /* The reason this while loop exists is that there * is a remote possibility of the above recv returning * less than 10 bytes. This is because a recv returns * as soon as there is some data, and will not wait for * all of the requested data to arrive. Since 10 bytes * is relatively small compared to the allowed TCP * packet sizes, a partial receive is unlikely. If * this example had used 2048 bytes requests instead, * a partial receive would be far more likely. * This loop will keep receiving until all 10 bytes * have been received, thus guaranteeing that the * next recv at the top of the loop will start at the * beginning of the next request. */ while (len < 10) { len1 = recv(0, &buf[len], 10-len, 0); if (len1 == -1) { exit (1); } len += len1; } /* This sleep simulates the processing of * the request that a real server may do. */ sleep(1); /* Send a response back to the client. */ if (send(0, buf, 10, 0) != 10) { exit (1); } } } /* The loop has terminated, because there are no * more requests to be serviced. 170 Chapter 8

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196

170
Chapter 8
Programming Hints
Adding a Server Process to the Internet Daemon
*
M A I N
*
*
This is the actual server routine that the /etc/inetd forks to
*
handle each individual connection.
Its purpose is to receive
*
the request packets from the remote client, process them,
*
and return the results to the client.
*
*/
main()
{
char buf[10];
/* This example uses 10 byte messages. */
int len, lenl;
/* Go into a loop, receiving requests from the remote
* client.
After the client has sent the last request,
* it will do a shutdown for sending, which will cause
* an end-of-file condition to appear on this end of the
* connection.
After all the client's requests have
* been received, the next recv call will return zero
* bytes, signaling an end-of-file condition.
This is
* how the server will know that no more requests will
* follow, and the loop will be exited.
*/
while (len = recv(0, buf, 10, 0)) {
if (len == -1) {
exit (1); /* error from recv */
}
/* The reason this while loop exists is that there
* is a remote possibility of the above recv returning
* less than 10 bytes.
This is because a recv returns
* as soon as there is some data, and will not wait for
* all of the requested data to arrive.
Since 10 bytes
* is relatively small compared to the allowed TCP
* packet sizes, a partial receive is unlikely.
If
* this example had used 2048 bytes requests instead,
* a partial receive would be far more likely.
* This loop will keep receiving until all 10 bytes
* have been received, thus guaranteeing that the
* next recv at the top of the loop will start at the
* beginning of the next request.
*/
while (len < 10) {
len1 = recv(0, &buf[len], 10-len, 0);
if (len1 == -1) {
exit (1);
}
len += len1;
}
/* This sleep simulates the processing of
* the request that a real server may do.
*/
sleep(1);
/* Send a response back to the client. */
if (send(0, buf, 10, 0) != 10) {
exit (1);
}
}
}
/* The loop has terminated, because there are no
* more requests to be serviced.