Thread: [Dev-C++] Socket Programming - Newbie - sockaddr 16 bytes?
Open Source C & C++ IDE for Windows
Brought to you by:
claplace
|
From: Peter D. <don...@ne...> - 2004-11-06 17:20:24
|
Hi,
Can someone tell me why it is important to fill out a sockaddr structure
to 16 bytes.
Reading a book it says that the structure is as follows:
struct sockaddr {
unsigned short sa_family;
char sa_data[14];
}
Why fill it out to 16 bytes? Is this a magic number in computers?
If the address family I choose is AF_INET then how do I know that this
takes only 2 bytes in the structure? Is there a way to calculate this?
How do I know that I need to set sa_data to 14 and not 15?
Any information regarding this would be great.
Many thanks,
Peter.
|
|
From: Obi <ob...@ch...> - 2004-11-06 18:50:12
|
At 02:20 07/11/2004 +0900, Peter Dennis wrote:
>Hi,
>
>Can someone tell me why it is important to fill out a sockaddr structure
>to 16 bytes.
>
>Reading a book it says that the structure is as follows:
>
>struct sockaddr {
> unsigned short sa_family;
> char sa_data[14];
>}
>
>Why fill it out to 16 bytes? Is this a magic number in computers?
>
>If the address family I choose is AF_INET then how do I know that this
>takes only 2 bytes in the structure? Is there a way to calculate this?
>How do I know that I need to set sa_data to 14 and not 15?
>
>Any information regarding this would be great.
>
>Many thanks,
>Peter.
socakaddr is a generic structure for all family types used to pass addresses
to functions that don't depend on the family type.
If you use AF_INET you should use the sockaddr_in definition to manipulate
the data.
Use a reinterpret_cast<> to swap between the two defs for the
same in-memory data.
e.g.
m_listenSocket = socket( AF_INET, SOCK_STREAM, 0 );
// Bind Socket
sockaddr_in lsa;
memset( &lsa, 0, sizeof(lsa) );
lsa.sin_family = AF_INET;
lsa.sin_port = htons( LISTEN_PORT );
lsa.sin_addr.s_addr = htonl( INADDR_ANY );
SOCKET ls;
bind( ls, reinterpret_cast<sockaddr*>( &lsa ), sizeof(lsa) );
// Listen on socket
listen( ls, QSIZE );
Hope this helps,
O
|
|
From: Daniel K. O. <dan...@ya...> - 2004-11-06 20:11:57
|
Obi wrote: > m_listenSocket = socket( AF_INET, SOCK_STREAM, 0 ); This is not right. Never call socket() with an AF_ argument; it should be PF_ (PF_INET in this case). AF_INET just "works" here by coincidence, because most of the BSD-sockets implementations use the same value for them. This is just as correct as using "socket(2, 1, 0);". Daniel K. O. |
|
From: <sa...@op...> - 2004-11-06 23:13:03
|
> Obi wrote: > >> m_listenSocket = socket( AF_INET, SOCK_STREAM, 0 ); > > > This is not right. Never call socket() with an AF_ argument; it should > be PF_ (PF_INET in this case). AF_INET just "works" here by coincidence, > because most of the BSD-sockets implementations use the same value for > them. This is just as correct as using "socket(2, 1, 0);". > This is not exactly true. The BSD standard says that the AF_ value will be the same as PF_ value (this could be found on linux man pages). But you are right, the value should be PF_INET because it describes the protocol family not the address family. --- Krzysztof Kapuscik |
|
From: Daniel K. O. <dan...@ya...> - 2004-11-07 04:07:01
|
Krzysztof Kapuścik wrote: > This is not exactly true. The BSD standard says that the AF_ value > will be the same as PF_ value (this could be found on linux man pages). Hm... really? From what I remember, it says they are *generally* the same, but I may be wrong. I'm curious now, does anyone know if it's possible to find on the internet exactly what the BSD standard says? (for free, obviously... I don't want to buy a book, I'm not THAT curious) Daniel K. O. |
|
From: Obi <ob...@ch...> - 2004-11-07 06:51:14
|
At 02:06 07/11/2004 -0200, Daniel K. O. wrote: >Krzysztof Kapu=C5=9Bcik wrote: > >>This is not exactly true. The BSD standard says that the AF_ value will=20 >>be the same as PF_ value (this could be found on linux man pages). > >Hm... really? From what I remember, it says they are *generally* the same,= =20 >but I may be wrong. >I'm curious now, does anyone know if it's possible to find on the internet= =20 >exactly what the BSD standard says? (for free, obviously... I don't want=20 >to buy a book, I'm not THAT curious) This is getting confusing now, the linux manpage lists the PF_ values, but= =20 refers to AF_ later on. The BSD manpage I found uses AF_ http://www.neosoft.com/neosoft/man/socket.2.html .. int socket(int domain, int type, int protocol) .. The domain parameter specifies a communications domain within which=20 communication will take place; this selects the protocol family which=20 should be used. These families are defined in the include file=20 <sys/socket.h>. The currently understood formats are .. AF_UNIX (UNIX internal protocols), AF_INET (ARPA Internet protocols), AF_ISO.... Hmmmmm. Also the Win32 docs call this parameter "address family" rather than=20 "protocol family".I don't have access to BSD or POSIX specs so I don't know= =20 the official line. It's a mystery.:-) |
|
From: <sa...@op...> - 2004-11-07 07:07:13
|
Daniel K. O. napisał(a): > Krzysztof Kapuścik wrote: > >> This is not exactly true. The BSD standard says that the AF_ value >> will be the same as PF_ value (this could be found on linux man pages). > > > Hm... really? From what I remember, it says they are *generally* the > same, but I may be wrong. > I'm curious now, does anyone know if it's possible to find on the > internet exactly what the BSD standard says? (for free, obviously... I > don't want to buy a book, I'm not THAT curious) > You could be right. I don't have the standard so I cannot be sure - if I am wrong and anyone have more accurate information - please reply. In Linux socket.h header file you can find: #define PF_INET x #define ... /* Address families AF_ - same as PF_ */ <== note this I think we could assume that the values will be always equal. Why? Just because there are so many sources using AF_INET (as I found in google the PF_INET was added later, so AF_INET was used before) - any change in standard will make them not runnable. The only addition will probably be adding some other AF_ to one PF_ (many address families for one protocol family) but probably it will be done this way: #define AF_INET PF_INET #define AF_SUPERINET (PF_INET + 1) #define AF_UNIT PF_UNIX to provide compability (this could be not true, it's just my imagination). The third thing is that socket() (as I found in google) checks for both AF_INET and PF_INET in function call and for sockaddr address family definition too - so probably it the contants change (AF_ not equal PF_) the socket() will work good. --- Have a nice day, Krzysztof Kapuscik |
|
From: Daniel K. O. <dan...@ya...> - 2004-11-07 13:14:11
|
Krzysztof Kapuścik wrote: > You could be right. I don't have the standard so I cannot be sure - if > I am wrong and anyone have more accurate information - please reply. > > In Linux socket.h header file you can find: > #define PF_INET x > #define ... > /* Address families AF_ - same as PF_ */ <== note this > > I think we could assume that the values will be always equal. Why? > Just because there are so many sources using AF_INET Then you could also assume that PF_INET == AF_INET == 2, and this can be considered right too: socket(2, 1, 6); /* "everybody" uses the same values anyways, so this is "safe" */ I even found on a Google search people writing references saying that the correct way is to use: socket(AF_INET, SOCK_STREAM, PF_INET); Now *this one* I know for sure it's wrong, but if you type exactly this on a Google search, you'll get some hits of people actually using this. > The third thing is that socket() (as I found in google) checks for both > AF_INET and PF_INET in function call and for sockaddr address family > definition too - so probably it the contants change (AF_ not equal > PF_) the socket() will work good. Yeah, probably. But anyways, I prefer using PF_INET for a socket() call, so I'll be sure that if I need to use the code on a "bizarre" (but working) sockets implementation, this can't cause any problem. Daniel K. O. |
|
From: Per W. <pw...@ia...> - 2004-11-07 14:07:15
|
The best thing with google is that if you misspell a word, you are likely to find a lot of hits anyway because of the huge number of indexed pages. Just the same with example source code. /Per W On Sun, 7 Nov 2004, Daniel K. O. wrote: > Krzysztof Kapu=C5=9Bcik wrote: > > > You could be right. I don't have the standard so I cannot be sure - if > > I am wrong and anyone have more accurate information - please reply. > > > > In Linux socket.h header file you can find: > > #define PF_INET x > > #define ... > > /* Address families AF_ - same as PF_ */ <=3D=3D note this > > > > I think we could assume that the values will be always equal. Why? > > Just because there are so many sources using AF_INET > > Then you could also assume that PF_INET =3D=3D AF_INET =3D=3D 2, and this= can be > considered right too: > > socket(2, 1, 6); /* "everybody" uses the same values anyways, so this > is "safe" */ > > > I even found on a Google search people writing references saying that > the correct way is to use: > > socket(AF_INET, SOCK_STREAM, PF_INET); > > Now *this one* I know for sure it's wrong, but if you type exactly this > on a Google search, you'll get some hits of people actually using this. > > > > The third thing is that socket() (as I found in google) checks for both > > AF_INET and PF_INET in function call and for sockaddr address family > > definition too - so probably it the contants change (AF_ not equal > > PF_) the socket() will work good. > > Yeah, probably. > But anyways, I prefer using PF_INET for a socket() call, so I'll be sure > that if I need to use the code on a "bizarre" (but working) sockets > implementation, this can't cause any problem. > > > > Daniel K. O. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick > _______________________________________________ > Dev-cpp-users mailing list > Dev...@li... > TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm > https://lists.sourceforge.net/lists/listinfo/dev-cpp-users > |
|
From: Obi <ob...@ch...> - 2004-11-07 00:36:55
|
At 18:10 06/11/2004 -0200, Daniel K. O. wrote: >Obi wrote: > >> ls = socket( AF_INET, SOCK_STREAM, 0 ); > >This is not right. Never call socket() with an AF_ argument; it should be >PF_ (PF_INET in this case). AF_INET just "works" here by coincidence, >because most of the BSD-sockets implementations use the same value for >them. This is just as correct as using "socket(2, 1, 0);". You're right, my mistake. AF_ defines are for the sockaddr structures & PF_ for the socket call. However most of the literature uses AF_ for the socket call too. ( Some docs I have specifically say to use AF_ defines ). FYI the above formcompiled and ran fine on Win32, Solaris & Linux. |
|
From: Daniel K. O. <dan...@ya...> - 2004-11-07 13:23:20
|
Obi wrote:
> You're right, my mistake. AF_ defines are for the sockaddr structures
> & PF_ for the socket call. However most
> of the literature uses AF_ for the socket call too. ( Some docs I have
> specifically say to use AF_ defines ).
Yes. The docs say different things, that's why I asked in the other
e-mail for the standard...
My offline Winsock 1 reference ("winsock.hlp") says:
---
SOCKET PASCAL FAR socket ( int af, int type, int protocol );
af An address format specification. The only format currently
supported is PF_INET, which is the ARPA Internet address format.
---
The MSDN's Winsock 2 reference for socket() doesn't say a word about the
constant that should be used.
Some articles there use AF_INET, but reference implementations mostly
use PF_INET (e.g.:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/ipv6_enabled_server_code_2.asp
).
Daniel K. O.
|