forked from lattera/glibc
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathsocket.texi
3647 lines (3074 loc) · 153 KB
/
socket.texi
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
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
@node Sockets, Low-Level Terminal Interface, Pipes and FIFOs, Top
@c %MENU% A more complicated IPC mechanism, with networking support
@chapter Sockets
This chapter describes the GNU facilities for interprocess
communication using sockets.
@cindex socket
@cindex interprocess communication, with sockets
A @dfn{socket} is a generalized interprocess communication channel.
Like a pipe, a socket is represented as a file descriptor. Unlike pipes
sockets support communication between unrelated processes, and even
between processes running on different machines that communicate over a
network. Sockets are the primary means of communicating with other
machines; @code{telnet}, @code{rlogin}, @code{ftp}, @code{talk} and the
other familiar network programs use sockets.
Not all operating systems support sockets. In @theglibc{}, the
header file @file{sys/socket.h} exists regardless of the operating
system, and the socket functions always exist, but if the system does
not really support sockets these functions always fail.
@strong{Incomplete:} We do not currently document the facilities for
broadcast messages or for configuring Internet interfaces. The
reentrant functions and some newer functions that are related to IPv6
aren't documented either so far.
@menu
* Socket Concepts:: Basic concepts you need to know about.
* Communication Styles::Stream communication, datagrams and other styles.
* Socket Addresses:: How socket names (``addresses'') work.
* Interface Naming:: Identifying specific network interfaces.
* Local Namespace:: Details about the local namespace.
* Internet Namespace:: Details about the Internet namespace.
* Misc Namespaces:: Other namespaces not documented fully here.
* Open/Close Sockets:: Creating sockets and destroying them.
* Connections:: Operations on sockets with connection state.
* Datagrams:: Operations on datagram sockets.
* Inetd:: Inetd is a daemon that starts servers on request.
The most convenient way to write a server
is to make it work with Inetd.
* Socket Options:: Miscellaneous low-level socket options.
* Networks Database:: Accessing the database of network names.
@end menu
@node Socket Concepts
@section Socket Concepts
@cindex communication style (of a socket)
@cindex style of communication (of a socket)
When you create a socket, you must specify the style of communication
you want to use and the type of protocol that should implement it.
The @dfn{communication style} of a socket defines the user-level
semantics of sending and receiving data on the socket. Choosing a
communication style specifies the answers to questions such as these:
@itemize @bullet
@item
@cindex packet
@cindex byte stream
@cindex stream (sockets)
@strong{What are the units of data transmission?} Some communication
styles regard the data as a sequence of bytes with no larger
structure; others group the bytes into records (which are known in
this context as @dfn{packets}).
@item
@cindex loss of data on sockets
@cindex data loss on sockets
@strong{Can data be lost during normal operation?} Some communication
styles guarantee that all the data sent arrives in the order it was
sent (barring system or network crashes); other styles occasionally
lose data as a normal part of operation, and may sometimes deliver
packets more than once or in the wrong order.
Designing a program to use unreliable communication styles usually
involves taking precautions to detect lost or misordered packets and
to retransmit data as needed.
@item
@strong{Is communication entirely with one partner?} Some
communication styles are like a telephone call---you make a
@dfn{connection} with one remote socket and then exchange data
freely. Other styles are like mailing letters---you specify a
destination address for each message you send.
@end itemize
@cindex namespace (of socket)
@cindex domain (of socket)
@cindex socket namespace
@cindex socket domain
You must also choose a @dfn{namespace} for naming the socket. A socket
name (``address'') is meaningful only in the context of a particular
namespace. In fact, even the data type to use for a socket name may
depend on the namespace. Namespaces are also called ``domains'', but we
avoid that word as it can be confused with other usage of the same
term. Each namespace has a symbolic name that starts with @samp{PF_}.
A corresponding symbolic name starting with @samp{AF_} designates the
address format for that namespace.
@cindex network protocol
@cindex protocol (of socket)
@cindex socket protocol
@cindex protocol family
Finally you must choose the @dfn{protocol} to carry out the
communication. The protocol determines what low-level mechanism is used
to transmit and receive data. Each protocol is valid for a particular
namespace and communication style; a namespace is sometimes called a
@dfn{protocol family} because of this, which is why the namespace names
start with @samp{PF_}.
The rules of a protocol apply to the data passing between two programs,
perhaps on different computers; most of these rules are handled by the
operating system and you need not know about them. What you do need to
know about protocols is this:
@itemize @bullet
@item
In order to have communication between two sockets, they must specify
the @emph{same} protocol.
@item
Each protocol is meaningful with particular style/namespace
combinations and cannot be used with inappropriate combinations. For
example, the TCP protocol fits only the byte stream style of
communication and the Internet namespace.
@item
For each combination of style and namespace there is a @dfn{default
protocol}, which you can request by specifying 0 as the protocol
number. And that's what you should normally do---use the default.
@end itemize
Throughout the following description at various places
variables/parameters to denote sizes are required. And here the trouble
starts. In the first implementations the type of these variables was
simply @code{int}. On most machines at that time an @code{int} was 32
bits wide, which created a @emph{de facto} standard requiring 32-bit
variables. This is important since references to variables of this type
are passed to the kernel.
Then the POSIX people came and unified the interface with the words "all
size values are of type @code{size_t}". On 64-bit machines
@code{size_t} is 64 bits wide, so pointers to variables were no longer
possible.
The Unix98 specification provides a solution by introducing a type
@code{socklen_t}. This type is used in all of the cases that POSIX
changed to use @code{size_t}. The only requirement of this type is that
it be an unsigned type of at least 32 bits. Therefore, implementations
which require that references to 32-bit variables be passed can be as
happy as implementations which use 64-bit values.
@node Communication Styles
@section Communication Styles
@Theglibc{} includes support for several different kinds of sockets,
each with different characteristics. This section describes the
supported socket types. The symbolic constants listed here are
defined in @file{sys/socket.h}.
@pindex sys/socket.h
@deftypevr Macro int SOCK_STREAM
@standards{BSD, sys/socket.h}
The @code{SOCK_STREAM} style is like a pipe (@pxref{Pipes and FIFOs}).
It operates over a connection with a particular remote socket and
transmits data reliably as a stream of bytes.
Use of this style is covered in detail in @ref{Connections}.
@end deftypevr
@deftypevr Macro int SOCK_DGRAM
@standards{BSD, sys/socket.h}
The @code{SOCK_DGRAM} style is used for sending
individually-addressed packets unreliably.
It is the diametrical opposite of @code{SOCK_STREAM}.
Each time you write data to a socket of this kind, that data becomes
one packet. Since @code{SOCK_DGRAM} sockets do not have connections,
you must specify the recipient address with each packet.
The only guarantee that the system makes about your requests to
transmit data is that it will try its best to deliver each packet you
send. It may succeed with the sixth packet after failing with the
fourth and fifth packets; the seventh packet may arrive before the
sixth, and may arrive a second time after the sixth.
The typical use for @code{SOCK_DGRAM} is in situations where it is
acceptable to simply re-send a packet if no response is seen in a
reasonable amount of time.
@xref{Datagrams}, for detailed information about how to use datagram
sockets.
@end deftypevr
@ignore
@c This appears to be only for the NS domain, which we aren't
@c discussing and probably won't support either.
@deftypevr Macro int SOCK_SEQPACKET
@standards{BSD, sys/socket.h}
This style is like @code{SOCK_STREAM} except that the data are
structured into packets.
A program that receives data over a @code{SOCK_SEQPACKET} socket
should be prepared to read the entire message packet in a single call
to @code{read}; if it only reads part of the message, the remainder of
the message is simply discarded instead of being available for
subsequent calls to @code{read}.
Many protocols do not support this communication style.
@end deftypevr
@end ignore
@ignore
@deftypevr Macro int SOCK_RDM
@standards{BSD, sys/socket.h}
This style is a reliable version of @code{SOCK_DGRAM}: it sends
individually addressed packets, but guarantees that each packet sent
arrives exactly once.
@strong{Warning:} It is not clear this is actually supported
by any operating system.
@end deftypevr
@end ignore
@deftypevr Macro int SOCK_RAW
@standards{BSD, sys/socket.h}
This style provides access to low-level network protocols and
interfaces. Ordinary user programs usually have no need to use this
style.
@end deftypevr
@node Socket Addresses
@section Socket Addresses
@cindex address of socket
@cindex name of socket
@cindex binding a socket address
@cindex socket address (name) binding
The name of a socket is normally called an @dfn{address}. The
functions and symbols for dealing with socket addresses were named
inconsistently, sometimes using the term ``name'' and sometimes using
``address''. You can regard these terms as synonymous where sockets
are concerned.
A socket newly created with the @code{socket} function has no
address. Other processes can find it for communication only if you
give it an address. We call this @dfn{binding} the address to the
socket, and the way to do it is with the @code{bind} function.
You need only be concerned with the address of a socket if other processes
are to find it and start communicating with it. You can specify an
address for other sockets, but this is usually pointless; the first time
you send data from a socket, or use it to initiate a connection, the
system assigns an address automatically if you have not specified one.
Occasionally a client needs to specify an address because the server
discriminates based on address; for example, the rsh and rlogin
protocols look at the client's socket address and only bypass passphrase
checking if it is less than @code{IPPORT_RESERVED} (@pxref{Ports}).
The details of socket addresses vary depending on what namespace you are
using. @xref{Local Namespace}, or @ref{Internet Namespace}, for specific
information.
Regardless of the namespace, you use the same functions @code{bind} and
@code{getsockname} to set and examine a socket's address. These
functions use a phony data type, @code{struct sockaddr *}, to accept the
address. In practice, the address lives in a structure of some other
data type appropriate to the address format you are using, but you cast
its address to @code{struct sockaddr *} when you pass it to
@code{bind}.
@menu
* Address Formats:: About @code{struct sockaddr}.
* Setting Address:: Binding an address to a socket.
* Reading Address:: Reading the address of a socket.
@end menu
@node Address Formats
@subsection Address Formats
The functions @code{bind} and @code{getsockname} use the generic data
type @code{struct sockaddr *} to represent a pointer to a socket
address. You can't use this data type effectively to interpret an
address or construct one; for that, you must use the proper data type
for the socket's namespace.
Thus, the usual practice is to construct an address of the proper
namespace-specific type, then cast a pointer to @code{struct sockaddr *}
when you call @code{bind} or @code{getsockname}.
The one piece of information that you can get from the @code{struct
sockaddr} data type is the @dfn{address format designator}. This tells
you which data type to use to understand the address fully.
@pindex sys/socket.h
The symbols in this section are defined in the header file
@file{sys/socket.h}.
@deftp {Data Type} {struct sockaddr}
@standards{BSD, sys/socket.h}
The @code{struct sockaddr} type itself has the following members:
@table @code
@item short int sa_family
This is the code for the address format of this address. It
identifies the format of the data which follows.
@item char sa_data[14]
This is the actual socket address data, which is format-dependent. Its
length also depends on the format, and may well be more than 14. The
length 14 of @code{sa_data} is essentially arbitrary.
@end table
@end deftp
Each address format has a symbolic name which starts with @samp{AF_}.
Each of them corresponds to a @samp{PF_} symbol which designates the
corresponding namespace. Here is a list of address format names:
@vtable @code
@item AF_LOCAL
@standards{POSIX, sys/socket.h}
This designates the address format that goes with the local namespace.
(@code{PF_LOCAL} is the name of that namespace.) @xref{Local Namespace
Details}, for information about this address format.
@item AF_UNIX
@standards{BSD, sys/socket.h}
@standards{Unix98, sys/socket.h}
This is a synonym for @code{AF_LOCAL}. Although @code{AF_LOCAL} is
mandated by POSIX.1g, @code{AF_UNIX} is portable to more systems.
@code{AF_UNIX} was the traditional name stemming from BSD, so even most
POSIX systems support it. It is also the name of choice in the Unix98
specification. (The same is true for @code{PF_UNIX}
vs. @code{PF_LOCAL}).
@item AF_FILE
@standards{GNU, sys/socket.h}
This is another synonym for @code{AF_LOCAL}, for compatibility.
(@code{PF_FILE} is likewise a synonym for @code{PF_LOCAL}.)
@item AF_INET
@standards{BSD, sys/socket.h}
This designates the address format that goes with the Internet
namespace. (@code{PF_INET} is the name of that namespace.)
@xref{Internet Address Formats}.
@item AF_INET6
@standards{IPv6 Basic API, sys/socket.h}
This is similar to @code{AF_INET}, but refers to the IPv6 protocol.
(@code{PF_INET6} is the name of the corresponding namespace.)
@item AF_UNSPEC
@standards{BSD, sys/socket.h}
This designates no particular address format. It is used only in rare
cases, such as to clear out the default destination address of a
``connected'' datagram socket. @xref{Sending Datagrams}.
The corresponding namespace designator symbol @code{PF_UNSPEC} exists
for completeness, but there is no reason to use it in a program.
@end vtable
@file{sys/socket.h} defines symbols starting with @samp{AF_} for many
different kinds of networks, most or all of which are not actually
implemented. We will document those that really work as we receive
information about how to use them.
@node Setting Address
@subsection Setting the Address of a Socket
@pindex sys/socket.h
Use the @code{bind} function to assign an address to a socket. The
prototype for @code{bind} is in the header file @file{sys/socket.h}.
For examples of use, see @ref{Local Socket Example}, or see @ref{Inet Example}.
@deftypefun int bind (int @var{socket}, struct sockaddr *@var{addr}, socklen_t @var{length})
@standards{BSD, sys/socket.h}
@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
@c Direct syscall, except on Hurd.
The @code{bind} function assigns an address to the socket
@var{socket}. The @var{addr} and @var{length} arguments specify the
address; the detailed format of the address depends on the namespace.
The first part of the address is always the format designator, which
specifies a namespace, and says that the address is in the format of
that namespace.
The return value is @code{0} on success and @code{-1} on failure. The
following @code{errno} error conditions are defined for this function:
@table @code
@item EBADF
The @var{socket} argument is not a valid file descriptor.
@item ENOTSOCK
The descriptor @var{socket} is not a socket.
@item EADDRNOTAVAIL
The specified address is not available on this machine.
@item EADDRINUSE
Some other socket is already using the specified address.
@item EINVAL
The socket @var{socket} already has an address.
@item EACCES
You do not have permission to access the requested address. (In the
Internet domain, only the super-user is allowed to specify a port number
in the range 0 through @code{IPPORT_RESERVED} minus one; see
@ref{Ports}.)
@end table
Additional conditions may be possible depending on the particular namespace
of the socket.
@end deftypefun
@node Reading Address
@subsection Reading the Address of a Socket
@pindex sys/socket.h
Use the function @code{getsockname} to examine the address of an
Internet socket. The prototype for this function is in the header file
@file{sys/socket.h}.
@deftypefun int getsockname (int @var{socket}, struct sockaddr *@var{addr}, socklen_t *@var{length-ptr})
@standards{BSD, sys/socket.h}
@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{@acsmem{/hurd}}}
@c Direct syscall, except on Hurd, where it seems like it might leak
@c VM if cancelled.
The @code{getsockname} function returns information about the
address of the socket @var{socket} in the locations specified by the
@var{addr} and @var{length-ptr} arguments. Note that the
@var{length-ptr} is a pointer; you should initialize it to be the
allocation size of @var{addr}, and on return it contains the actual
size of the address data.
The format of the address data depends on the socket namespace. The
length of the information is usually fixed for a given namespace, so
normally you can know exactly how much space is needed and can provide
that much. The usual practice is to allocate a place for the value
using the proper data type for the socket's namespace, then cast its
address to @code{struct sockaddr *} to pass it to @code{getsockname}.
The return value is @code{0} on success and @code{-1} on error. The
following @code{errno} error conditions are defined for this function:
@table @code
@item EBADF
The @var{socket} argument is not a valid file descriptor.
@item ENOTSOCK
The descriptor @var{socket} is not a socket.
@item ENOBUFS
There are not enough internal buffers available for the operation.
@end table
@end deftypefun
You can't read the address of a socket in the file namespace. This is
consistent with the rest of the system; in general, there's no way to
find a file's name from a descriptor for that file.
@node Interface Naming
@section Interface Naming
Each network interface has a name. This usually consists of a few
letters that relate to the type of interface, which may be followed by a
number if there is more than one interface of that type. Examples
might be @code{lo} (the loopback interface) and @code{eth0} (the first
Ethernet interface).
Although such names are convenient for humans, it would be clumsy to
have to use them whenever a program needs to refer to an interface. In
such situations an interface is referred to by its @dfn{index}, which is
an arbitrarily-assigned small positive integer.
The following functions, constants and data types are declared in the
header file @file{net/if.h}.
@deftypevr Constant size_t IFNAMSIZ
@standards{???, net/if.h}
This constant defines the maximum buffer size needed to hold an
interface name, including its terminating zero byte.
@end deftypevr
@deftypefun {unsigned int} if_nametoindex (const char *@var{ifname})
@standards{IPv6 basic API, net/if.h}
@safety{@prelim{}@mtsafe{}@asunsafe{@asulock{}}@acunsafe{@aculock{} @acsfd{}}}
@c It opens a socket to use ioctl on the fd to get the index.
@c opensock may call socket and access multiple times until it finds a
@c socket family that works. The Linux implementation has a potential
@c concurrency issue WRT last_type and last_family not being updated
@c atomically, but it is harmless; the generic implementation, OTOH,
@c takes a lock, which makes all callers AS- and AC-Unsafe.
@c opensock @asulock @aculock @acsfd
This function yields the interface index corresponding to a particular
name. If no interface exists with the name given, it returns 0.
@end deftypefun
@deftypefun {char *} if_indextoname (unsigned int @var{ifindex}, char *@var{ifname})
@standards{IPv6 basic API, net/if.h}
@safety{@prelim{}@mtsafe{}@asunsafe{@asulock{}}@acunsafe{@aculock{} @acsfd{}}}
@c It opens a socket with opensock to use ioctl on the fd to get the
@c name from the index.
This function maps an interface index to its corresponding name. The
returned name is placed in the buffer pointed to by @code{ifname}, which
must be at least @code{IFNAMSIZ} bytes in length. If the index was
invalid, the function's return value is a null pointer, otherwise it is
@code{ifname}.
@end deftypefun
@deftp {Data Type} {struct if_nameindex}
@standards{IPv6 basic API, net/if.h}
This data type is used to hold the information about a single
interface. It has the following members:
@table @code
@item unsigned int if_index;
This is the interface index.
@item char *if_name
This is the null-terminated index name.
@end table
@end deftp
@deftypefun {struct if_nameindex *} if_nameindex (void)
@standards{IPv6 basic API, net/if.h}
@safety{@prelim{}@mtsafe{}@asunsafe{@ascuheap{} @asulock{/hurd}}@acunsafe{@aculock{/hurd} @acsfd{} @acsmem{}}}
@c if_nameindex @ascuheap @asulock/hurd @aculock/hurd @acsfd @acsmem
@c [linux]
@c netlink_open @acsfd @acsmem/hurd
@c socket dup @acsfd
@c memset dup ok
@c bind dup ok
@c netlink_close dup @acsfd
@c getsockname dup @acsmem/hurd
@c netlink_request @ascuheap @acsmem
@c getpagesize dup ok
@c malloc dup @ascuheap @acsmem
@c netlink_sendreq ok
@c memset dup ok
@c sendto dup ok
@c recvmsg dup ok
@c memcpy dup ok
@c free dup @ascuheap @acsmem
@c netlink_free_handle @ascuheap @acsmem
@c free dup @ascuheap @acsmem
@c netlink_close @acsfd
@c close dup @acsfd
@c malloc dup @asuheap @acsmem
@c strndup @ascuheap @acsmem
@c if_freenameindex @ascuheap @acsmem
@c [hurd]
@c opensock dup @asulock @aculock @acsfd
@c hurd_socket_server ok
@c pfinet_siocgifconf ok
@c malloc @ascuheap @acsmem
@c strdup @ascuheap @acsmem
@c ioctl dup ok
@c free @ascuheap @acsmem
This function returns an array of @code{if_nameindex} structures, one
for every interface that is present. The end of the list is indicated
by a structure with an interface of 0 and a null name pointer. If an
error occurs, this function returns a null pointer.
The returned structure must be freed with @code{if_freenameindex} after
use.
@end deftypefun
@deftypefun void if_freenameindex (struct if_nameindex *@var{ptr})
@standards{IPv6 basic API, net/if.h}
@safety{@prelim{}@mtsafe{}@asunsafe{@ascuheap{}}@acunsafe{@acsmem{}}}
@c if_freenameindex @ascuheap @acsmem
@c free dup @ascuheap @acsmem
This function frees the structure returned by an earlier call to
@code{if_nameindex}.
@end deftypefun
@node Local Namespace
@section The Local Namespace
@cindex local namespace, for sockets
This section describes the details of the local namespace, whose
symbolic name (required when you create a socket) is @code{PF_LOCAL}.
The local namespace is also known as ``Unix domain sockets''. Another
name is file namespace since socket addresses are normally implemented
as file names.
@menu
* Concepts: Local Namespace Concepts. What you need to understand.
* Details: Local Namespace Details. Address format, symbolic names, etc.
* Example: Local Socket Example. Example of creating a socket.
@end menu
@node Local Namespace Concepts
@subsection Local Namespace Concepts
In the local namespace socket addresses are file names. You can specify
any file name you want as the address of the socket, but you must have
write permission on the directory containing it.
@c XXX The following was said to be wrong.
@c In order to connect to a socket you must have read permission for it.
It's common to put these files in the @file{/tmp} directory.
One peculiarity of the local namespace is that the name is only used
when opening the connection; once open the address is not meaningful and
may not exist.
Another peculiarity is that you cannot connect to such a socket from
another machine--not even if the other machine shares the file system
which contains the name of the socket. You can see the socket in a
directory listing, but connecting to it never succeeds. Some programs
take advantage of this, such as by asking the client to send its own
process ID, and using the process IDs to distinguish between clients.
However, we recommend you not use this method in protocols you design,
as we might someday permit connections from other machines that mount
the same file systems. Instead, send each new client an identifying
number if you want it to have one.
After you close a socket in the local namespace, you should delete the
file name from the file system. Use @code{unlink} or @code{remove} to
do this; see @ref{Deleting Files}.
The local namespace supports just one protocol for any communication
style; it is protocol number @code{0}.
@node Local Namespace Details
@subsection Details of Local Namespace
@pindex sys/socket.h
To create a socket in the local namespace, use the constant
@code{PF_LOCAL} as the @var{namespace} argument to @code{socket} or
@code{socketpair}. This constant is defined in @file{sys/socket.h}.
@deftypevr Macro int PF_LOCAL
@standards{POSIX, sys/socket.h}
This designates the local namespace, in which socket addresses are local
names, and its associated family of protocols. @code{PF_LOCAL} is the
macro used by POSIX.1g.
@end deftypevr
@deftypevr Macro int PF_UNIX
@standards{BSD, sys/socket.h}
This is a synonym for @code{PF_LOCAL}, for compatibility's sake.
@end deftypevr
@deftypevr Macro int PF_FILE
@standards{GNU, sys/socket.h}
This is a synonym for @code{PF_LOCAL}, for compatibility's sake.
@end deftypevr
The structure for specifying socket names in the local namespace is
defined in the header file @file{sys/un.h}:
@pindex sys/un.h
@deftp {Data Type} {struct sockaddr_un}
@standards{BSD, sys/un.h}
This structure is used to specify local namespace socket addresses. It has
the following members:
@table @code
@item short int sun_family
This identifies the address family or format of the socket address.
You should store the value @code{AF_LOCAL} to designate the local
namespace. @xref{Socket Addresses}.
@item char sun_path[108]
This is the file name to use.
@strong{Incomplete:} Why is 108 a magic number? RMS suggests making
this a zero-length array and tweaking the following example to use
@code{alloca} to allocate an appropriate amount of storage based on
the length of the filename.
@end table
@end deftp
You should compute the @var{length} parameter for a socket address in
the local namespace as the sum of the size of the @code{sun_family}
component and the string length (@emph{not} the allocation size!) of
the file name string. This can be done using the macro @code{SUN_LEN}:
@deftypefn {Macro} int SUN_LEN (@emph{struct sockaddr_un *} @var{ptr})
@standards{BSD, sys/un.h}
@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
This macro computes the length of the socket address in the local namespace.
@end deftypefn
@node Local Socket Example
@subsection Example of Local-Namespace Sockets
Here is an example showing how to create and name a socket in the local
namespace.
@smallexample
@include mkfsock.c.texi
@end smallexample
@node Internet Namespace
@section The Internet Namespace
@cindex Internet namespace, for sockets
This section describes the details of the protocols and socket naming
conventions used in the Internet namespace.
Originally the Internet namespace used only IP version 4 (IPv4). With
the growing number of hosts on the Internet, a new protocol with a
larger address space was necessary: IP version 6 (IPv6). IPv6
introduces 128-bit addresses (IPv4 has 32-bit addresses) and other
features, and will eventually replace IPv4.
To create a socket in the IPv4 Internet namespace, use the symbolic name
@code{PF_INET} of this namespace as the @var{namespace} argument to
@code{socket} or @code{socketpair}. For IPv6 addresses you need the
macro @code{PF_INET6}. These macros are defined in @file{sys/socket.h}.
@pindex sys/socket.h
@deftypevr Macro int PF_INET
@standards{BSD, sys/socket.h}
This designates the IPv4 Internet namespace and associated family of
protocols.
@end deftypevr
@deftypevr Macro int PF_INET6
@standards{X/Open, sys/socket.h}
This designates the IPv6 Internet namespace and associated family of
protocols.
@end deftypevr
A socket address for the Internet namespace includes the following components:
@itemize @bullet
@item
The address of the machine you want to connect to. Internet addresses
can be specified in several ways; these are discussed in @ref{Internet
Address Formats}, @ref{Host Addresses} and @ref{Host Names}.
@item
A port number for that machine. @xref{Ports}.
@end itemize
You must ensure that the address and port number are represented in a
canonical format called @dfn{network byte order}. @xref{Byte Order},
for information about this.
@menu
* Internet Address Formats:: How socket addresses are specified in the
Internet namespace.
* Host Addresses:: All about host addresses of Internet host.
* Ports:: Internet port numbers.
* Services Database:: Ports may have symbolic names.
* Byte Order:: Different hosts may use different byte
ordering conventions; you need to
canonicalize host address and port number.
* Protocols Database:: Referring to protocols by name.
* Inet Example:: Putting it all together.
@end menu
@node Internet Address Formats
@subsection Internet Socket Address Formats
In the Internet namespace, for both IPv4 (@code{AF_INET}) and IPv6
(@code{AF_INET6}), a socket address consists of a host address
and a port on that host. In addition, the protocol you choose serves
effectively as a part of the address because local port numbers are
meaningful only within a particular protocol.
The data types for representing socket addresses in the Internet namespace
are defined in the header file @file{netinet/in.h}.
@pindex netinet/in.h
@deftp {Data Type} {struct sockaddr_in}
@standards{BSD, netinet/in.h}
This is the data type used to represent socket addresses in the
Internet namespace. It has the following members:
@table @code
@item sa_family_t sin_family
This identifies the address family or format of the socket address.
You should store the value @code{AF_INET} in this member.
@xref{Socket Addresses}.
@item struct in_addr sin_addr
This is the Internet address of the host machine. @xref{Host
Addresses}, and @ref{Host Names}, for how to get a value to store
here.
@item unsigned short int sin_port
This is the port number. @xref{Ports}.
@end table
@end deftp
When you call @code{bind} or @code{getsockname}, you should specify
@code{sizeof (struct sockaddr_in)} as the @var{length} parameter if
you are using an IPv4 Internet namespace socket address.
@deftp {Data Type} {struct sockaddr_in6}
This is the data type used to represent socket addresses in the IPv6
namespace. It has the following members:
@table @code
@item sa_family_t sin6_family
This identifies the address family or format of the socket address.
You should store the value of @code{AF_INET6} in this member.
@xref{Socket Addresses}.
@item struct in6_addr sin6_addr
This is the IPv6 address of the host machine. @xref{Host
Addresses}, and @ref{Host Names}, for how to get a value to store
here.
@item uint32_t sin6_flowinfo
This is a currently unimplemented field.
@item uint16_t sin6_port
This is the port number. @xref{Ports}.
@end table
@end deftp
@node Host Addresses
@subsection Host Addresses
Each computer on the Internet has one or more @dfn{Internet addresses},
numbers which identify that computer among all those on the Internet.
Users typically write IPv4 numeric host addresses as sequences of four
numbers, separated by periods, as in @samp{128.52.46.32}, and IPv6
numeric host addresses as sequences of up to eight numbers separated by
colons, as in @samp{5f03:1200:836f:c100::1}.
Each computer also has one or more @dfn{host names}, which are strings
of words separated by periods, as in @samp{www.gnu.org}.
Programs that let the user specify a host typically accept both numeric
addresses and host names. To open a connection a program needs a
numeric address, and so must convert a host name to the numeric address
it stands for.
@menu
* Abstract Host Addresses:: What a host number consists of.
* Data type: Host Address Data Type. Data type for a host number.
* Functions: Host Address Functions. Functions to operate on them.
* Names: Host Names. Translating host names to host numbers.
@end menu
@node Abstract Host Addresses
@subsubsection Internet Host Addresses
@cindex host address, Internet
@cindex Internet host address
@ifinfo
Each computer on the Internet has one or more Internet addresses,
numbers which identify that computer among all those on the Internet.
@end ifinfo
@cindex network number
@cindex local network address number
An IPv4 Internet host address is a number containing four bytes of data.
Historically these are divided into two parts, a @dfn{network number} and a
@dfn{local network address number} within that network. In the
mid-1990s classless addresses were introduced which changed this
behavior. Since some functions implicitly expect the old definitions,
we first describe the class-based network and will then describe
classless addresses. IPv6 uses only classless addresses and therefore
the following paragraphs don't apply.
The class-based IPv4 network number consists of the first one, two or
three bytes; the rest of the bytes are the local address.
IPv4 network numbers are registered with the Network Information Center
(NIC), and are divided into three classes---A, B and C. The local
network address numbers of individual machines are registered with the
administrator of the particular network.
Class A networks have single-byte numbers in the range 0 to 127. There
are only a small number of Class A networks, but they can each support a
very large number of hosts. Medium-sized Class B networks have two-byte
network numbers, with the first byte in the range 128 to 191. Class C
networks are the smallest; they have three-byte network numbers, with
the first byte in the range 192-255. Thus, the first 1, 2, or 3 bytes
of an Internet address specify a network. The remaining bytes of the
Internet address specify the address within that network.
The Class A network 0 is reserved for broadcast to all networks. In
addition, the host number 0 within each network is reserved for broadcast
to all hosts in that network. These uses are obsolete now but for
compatibility reasons you shouldn't use network 0 and host number 0.
The Class A network 127 is reserved for loopback; you can always use
the Internet address @samp{127.0.0.1} to refer to the host machine.
Since a single machine can be a member of multiple networks, it can
have multiple Internet host addresses. However, there is never
supposed to be more than one machine with the same host address.
@c !!! this section could document the IN_CLASS* macros in <netinet/in.h>.
@c No, it shouldn't since they're obsolete.
@cindex standard dot notation, for Internet addresses
@cindex dot notation, for Internet addresses
There are four forms of the @dfn{standard numbers-and-dots notation}
for Internet addresses:
@table @code
@item @var{a}.@var{b}.@var{c}.@var{d}
This specifies all four bytes of the address individually and is the
commonly used representation.
@item @var{a}.@var{b}.@var{c}
The last part of the address, @var{c}, is interpreted as a 2-byte quantity.
This is useful for specifying host addresses in a Class B network with
network address number @code{@var{a}.@var{b}}.
@item @var{a}.@var{b}
The last part of the address, @var{b}, is interpreted as a 3-byte quantity.
This is useful for specifying host addresses in a Class A network with
network address number @var{a}.
@item @var{a}
If only one part is given, this corresponds directly to the host address
number.
@end table
Within each part of the address, the usual C conventions for specifying
the radix apply. In other words, a leading @samp{0x} or @samp{0X} implies
hexadecimal radix; a leading @samp{0} implies octal; and otherwise decimal
radix is assumed.
@subsubheading Classless Addresses
IPv4 addresses (and IPv6 addresses also) are now considered classless;
the distinction between classes A, B and C can be ignored. Instead an
IPv4 host address consists of a 32-bit address and a 32-bit mask. The
mask contains set bits for the network part and cleared bits for the
host part. The network part is contiguous from the left, with the
remaining bits representing the host. As a consequence, the netmask can
simply be specified as the number of set bits. Classes A, B and C are
just special cases of this general rule. For example, class A addresses
have a netmask of @samp{255.0.0.0} or a prefix length of 8.
Classless IPv4 network addresses are written in numbers-and-dots
notation with the prefix length appended and a slash as separator. For
example the class A network 10 is written as @samp{10.0.0.0/8}.
@subsubheading IPv6 Addresses
IPv6 addresses contain 128 bits (IPv4 has 32 bits) of data. A host
address is usually written as eight 16-bit hexadecimal numbers that are
separated by colons. Two colons are used to abbreviate strings of
consecutive zeros. For example, the IPv6 loopback address
@samp{0:0:0:0:0:0:0:1} can just be written as @samp{::1}.
@node Host Address Data Type
@subsubsection Host Address Data Type
IPv4 Internet host addresses are represented in some contexts as integers
(type @code{uint32_t}). In other contexts, the integer is
packaged inside a structure of type @code{struct in_addr}. It would
be better if the usage were made consistent, but it is not hard to extract
the integer from the structure or put the integer into a structure.
You will find older code that uses @code{unsigned long int} for
IPv4 Internet host addresses instead of @code{uint32_t} or @code{struct
in_addr}. Historically @code{unsigned long int} was a 32-bit number but
with 64-bit machines this has changed. Using @code{unsigned long int}
might break the code if it is used on machines where this type doesn't
have 32 bits. @code{uint32_t} is specified by Unix98 and guaranteed to have
32 bits.
IPv6 Internet host addresses have 128 bits and are packaged inside a
structure of type @code{struct in6_addr}.
The following basic definitions for Internet addresses are declared in
the header file @file{netinet/in.h}:
@pindex netinet/in.h
@deftp {Data Type} {struct in_addr}
@standards{BSD, netinet/in.h}
This data type is used in certain contexts to contain an IPv4 Internet
host address. It has just one field, named @code{s_addr}, which records
the host address number as an @code{uint32_t}.
@end deftp
@deftypevr Macro {uint32_t} INADDR_LOOPBACK
@standards{BSD, netinet/in.h}
You can use this constant to stand for ``the address of this machine,''
instead of finding its actual address. It is the IPv4 Internet address
@samp{127.0.0.1}, which is usually called @samp{localhost}. This
special constant saves you the trouble of looking up the address of your
own machine. Also, the system usually implements @code{INADDR_LOOPBACK}
specially, avoiding any network traffic for the case of one machine
talking to itself.
@end deftypevr
@deftypevr Macro {uint32_t} INADDR_ANY
@standards{BSD, netinet/in.h}
You can use this constant to stand for ``any incoming address'' when
binding to an address. @xref{Setting Address}. This is the usual