[clug-progsig] the question about the 2nd and 3rd argument within accept() function.

[Reno L]

Thanks a lot. Your answer is perfect to clear my
puzzle. Would you C++/Linux experts come to the SIG
meeting tomorrow? I'd like to say thanks to whoever
helped me on C++ issues. As I remember, to Michale, to
Chris......

Reno


--- Chris Berry <chrisb at chrisbtoo.net> wrote:

> [Not entirely sure if I'm answering the question
> that was asked here,
> but since nobody else has jumped in, I'll give it a
> go]
> 
> Reno L wrote:
> 
> > int accept(int sockfd, struct sockaddr *cliaddr,
> > socklen_t *addrlen);
> > 
> > I am confused by the usage of the second argument,
> > which should be the client address.
> 
> 
> The 2nd argument is a pointer to a structure into
> which the client
> address will be written after the call to accept().
> The 3rd argument is 
> a pointer to a value that tells accept() how big
> that structure is on 
> the way in, and will contain the size of the address
> written on the way out.
> 
> For (very ugly) example:
> 
>      unsigned char mybuf[100]; /* just a load of
> bytes */
>      int bufsize=100; /* the size of the buffer */
>      accept(sockfd, &mybuf[0], &bufsize);
> 
>      /* at this point, bufsize contains the number
> of bytes written,
>         which will be 4 for AF_INET sockets */
> 
> This is quite a commonly used technique - you make a
> buffer and tell a 
> function how big it is, and to write data into it.
> It tells you how much 
> it wrote by updating the size variable. You quite
> often see things in 
> Win32 (spit!) where, if you pass a NULL pointer for
> the buffer, it'll 
> just write the size of the data required into the
> counter. For example:
> 
>      DWORD bufsize;
>      LPBYTE my_buffer;
> 
>      RegQueryValueEx(hKey, /* hKey */
>                      "MyRegistryKey", /* lpValueName
> */
>                      NULL, /* lpReserved */
>                      NULL, /* lpType */
>                      NULL, /* lpData - don't write
> any data */
>                      &bufsize); /* will write size
> of required buffer
>                                    here */
> 
>      my_buffer = malloc (bufsize);
> 
>      RegQueryValueEx(hKey, /* hKey */
>                      "MyRegistryKey", /* lpValueName
> */
>                      NULL, /* lpReserved */
>                      NULL, /* lpType */
>                      my_buffer, /* Write the data
> here this time */
>                      &bufsize); /* give us the count
> again */
> 
> 
> 
> > [...]
> > int sin_size;
> 
> FWIW, this should really be a socklen_t. If you ever
> tried compiling it 
> with a C++ compiler, you could probably expect pain.
> 
> 
> > Both getpeername() and accept() function won't
> know the remote client
> >  address information in the code. Who will pass
> this information to 
> > these two function in the Run-time? Will Kernal do
> it?
> 
> Those 2 functions act on an open socket. The TCP/IP
> stack / sockets 
> library will know the address, because accept()
> doesn't return until a 
> connection has been made (unless the socket has been
> configured to be 
> non-blocking). If there's a connection, then the
> stack will know the 
> remote address, and it can write it into the buffer.
> 
> Hope this helps, and didn't go off on too many
> tangents.
> 
> 
> Chris.
> 
> _______________________________________________
> clug-progsig mailing list
> clug-progsig at clug.ca
> http://clug.ca/mailman/listinfo/clug-progsig_clug.ca
> 



		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail