setsockopt() and local optval variable - TCP-IP

This is a discussion on setsockopt() and local optval variable - TCP-IP ; ------------------------- static int sock; // Stuff (creating socket): sock = socket(AF_INET, SOCK_DGRAM, 0); void setSockOpt() { int optval = 1; int retVal; retVal = setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, (char *)&optval, sizeof(optval)); // Stuff } ------------------------- 1. setsockopt() requires a pointer to ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: setsockopt() and local optval variable

  1. setsockopt() and local optval variable

    -------------------------
    static int sock;


    // Stuff (creating socket): sock = socket(AF_INET, SOCK_DGRAM, 0);


    void setSockOpt()
    {
    int optval = 1;
    int retVal;
    retVal = setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, (char *)&optval,

    sizeof(optval));
    // Stuff


    }


    -------------------------

    1. setsockopt() requires a pointer to optval;
    2. optval in setSockOpt() is _local_ variable (!!!)


    Question: Is the setSockOpt() valid? Can we use _local_ optval in
    example above?
    --
    Alex Vinokur
    email: alex DOT vinokur AT gmail DOT com
    http://mathforum.org/library/view/10978.html
    http://sourceforge.net/users/alexvn


  2. Re: setsockopt() and local optval variable


    Alex Vinokur wrote:

    > void setSockOpt()
    > {
    > int optval = 1;
    > int retVal;
    > retVal = setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, (char *)&optval,
    > sizeof(optval));
    > // Stuff
    > }


    > 1. setsockopt() requires a pointer to optval;
    > 2. optval in setSockOpt() is _local_ variable (!!!)


    > Question: Is the setSockOpt() valid? Can we use _local_ optval in
    > example above?


    This is just like most other system calls that take an address, like
    'read' and 'write'. The address is dereferenced during the system call
    but it isn't messed with afterwards.

    So yes, you can.

    DS


  3. Re: setsockopt() and local optval variable

    David Schwartz wrote:
    > Alex Vinokur wrote:
    >
    > > void setSockOpt()
    > > {
    > > int optval = 1;
    > > int retVal;
    > > retVal = setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, (char *)&optval,
    > > sizeof(optval));
    > > // Stuff
    > > }

    >
    > > 1. setsockopt() requires a pointer to optval;
    > > 2. optval in setSockOpt() is _local_ variable (!!!)

    >
    > > Question: Is the setSockOpt() valid? Can we use _local_ optval in
    > > example above?

    >
    > This is just like most other system calls


    Not all system calls?

    > that take an address, like 'read' and 'write'.
    > The address is dereferenced during the system call but it isn't messed with afterwards.


    On all systems?
    In other words, _must_ setsockopt() dereference the address during the
    system call?

    >
    > So yes, you can.
    >
    > DS


    Alex Vinokur
    email: alex DOT vinokur AT gmail DOT com
    http://mathforum.org/library/view/10978.html
    http://sourceforge.net/users/alexvn


  4. Re: setsockopt() and local optval variable

    "Alex Vinokur" writes:

    >> This is just like most other system calls


    >Not all system calls?


    There are system calls which cause an asynchronous and addresses given
    to those need to remain valid.

    >> that take an address, like 'read' and 'write'.
    >> The address is dereferenced during the system call but it isn't messed with afterwards.


    >On all systems?
    >In other words, _must_ setsockopt() dereference the address during the
    >system call?


    Yes. That is true for all calls, system of library, which do not
    specifically make statements about the live of the arguments.

    (E.g., it is NOT true for putenv(3C))


    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.

  5. Re: setsockopt() and local optval variable


    "David Schwartz" wrote in message news:1157270477.109490.277560@74g2000cwt.googlegro ups.com...
    >
    > Alex Vinokur wrote:
    >
    > > void setSockOpt()
    > > {
    > > int optval = 1;
    > > int retVal;
    > > retVal = setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, (char *)&optval,
    > > sizeof(optval));
    > > // Stuff
    > > }


    result = setsockopt(s, SOL_SOCKET, SO_SNDBUF, &buffsize,
    sizeof(buffsize));
    >
    > > 1. setsockopt() requires a pointer to optval;
    > > 2. optval in setSockOpt() is _local_ variable (!!!)

    >
    > > Question: Is the setSockOpt() valid? Can we use _local_ optval in
    > > example above?

    >
    > This is just like most other system calls that take an address, like
    > 'read' and 'write'. The address is dereferenced during the system call
    > but it isn't messed with afterwards.
    >
    > So yes, you can.
    >
    > DS
    >


    So, we can use the same optval variable to set different socket options (?).
    -----------------------------
    int optval;
    int retVal;

    optval = 1;
    retVal = setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, (char *)&optval, sizeof(optval));
    // Check retVal

    optval = 10000;
    retVal = setsockopt(sock, SOL_SOCKET, SO_SNDBUF, &optval, sizeof(optval));
    // Check retVal

    -----------------------------


    --
    Alex Vinokur
    email: alex DOT vinokur AT gmail DOT com
    http://mathforum.org/library/view/10978.html
    http://sourceforge.net/users/alexvn




  6. Re: setsockopt() and local optval variable

    In article <44fb0f2e$0$8150$834e42db@reader.greatnowhere.com>,
    "Alex Vinokur" wrote:

    > So, we can use the same optval variable to set different socket options (?).
    > -----------------------------
    > int optval;
    > int retVal;
    >
    > optval = 1;
    > retVal = setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, (char *)&optval,
    > sizeof(optval));
    > // Check retVal
    >
    > optval = 10000;
    > retVal = setsockopt(sock, SOL_SOCKET, SO_SNDBUF, &optval, sizeof(optval));
    > // Check retVal


    Yes. By the time setsockopt() has returned, the socket has been
    modified, and the optval is no longer used.

    The only reason this parameter is passed as an address is because
    different options take different length parameters, and this is the only
    way to pass variable-length parameters in C (you could pass an array,
    but it does essentially the same thing behind the scenes, since arrays
    are passed by address).

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  7. Re: setsockopt() and local optval variable


    Alex Vinokur wrote:

    > On all systems?
    > In other words, _must_ setsockopt() dereference the address during the
    > system call?


    No, but if it does not, it must not dereference it later.

    For example, if you try to turn off Nagle on a TCP connection that has
    closed, the implementation may just ignore the call and never
    dereference the pointer. But it certainly can't save the pointer and
    dereference it at some arbitrary later point.

    DS


  8. Re: setsockopt() and local optval variable

    David Schwartz wrote:
    > Alex Vinokur wrote:
    >
    > > On all systems?
    > > In other words, _must_ setsockopt() dereference the address during the
    > > system call?

    >
    > No, but if it does not,


    Are there any actual implementations of setsockopt() that don't
    dereference the address during the system call?
    On what operating systems (if such implementations exist)?

    > it must not dereference it later.

    [snip]

    Alex Vinokur
    email: alex DOT vinokur AT gmail DOT com
    http://mathforum.org/library/view/10978.html
    http://sourceforge.net/users/alexvn


  9. Re: setsockopt() and local optval variable

    Alex Vinokur wrote:
    > Are there any actual implementations of setsockopt() that don't
    > dereference the address during the system call?


    Any time you pass an unsupported option to setsockopt() it will behave
    like this: it will set errno and return without dereferencing the pointer.

    Why do you need this information?

  10. Re: setsockopt() and local optval variable

    EJP wrote:
    > Alex Vinokur wrote:
    > > Are there any actual implementations of setsockopt() that don't
    > > dereference the address during the system call?

    >
    > Any time you pass an unsupported option to setsockopt() it will behave
    > like this: it will set errno and return without dereferencing the pointer.
    >
    > Why do you need this information?


    What I wanted to know is: can we use setMySockOptVersion1(), or we have
    to use setMySockOptVersion2() or setMySockOptVersion3() (see below)?

    Barry Margolin has already answered that question at
    http://groups.google.com/group/comp....477ce40c7e5fc1


    -----------------------
    static int sock;

    void createSock
    {
    sock = socket(AF_INET, SOCK_DGRAM, 0);
    // Check retval
    }

    void setMySockOptVersion1()
    {
    int optval;
    int retval;

    optval = 1;
    retval = setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &optval,
    sizeof(optval));
    // Check retval

    optval = 10000;
    retval = setsockopt(sock, SOL_SOCKET, SO_SNDBUF, &optval,
    sizeof(optval));
    // Check retval
    }

    void setMySockOptVersion2()
    {
    int optval1 = 1;
    int optval2 = 10000;
    int retval;

    retval = setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &optval1,
    sizeof(optval1));
    // Check retval

    retval = setsockopt(sock, SOL_SOCKET, SO_SNDBUF, &optval2,
    sizeof(optval2));
    // Check retval
    }

    void setMySockOptVersion3()
    {
    int* optval1 = new int ();
    int* optval2 = new int ();
    int retval;

    *optval1 = 1;
    retval = setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, optval1,
    sizeof(*optval1));
    // Check retval

    *optval2 = 10000;
    retval = setsockopt(sock, SOL_SOCKET, SO_SNDBUF, optval2,
    sizeof(*optval2));
    // Check retval

    // optval1 and optval2 will be deleted after closing sock;
    }
    -----------------------

    Alex Vinokur
    email: alex DOT vinokur AT gmail DOT com
    http://mathforum.org/library/view/10978.html
    http://sourceforge.net/users/alexvn


+ Reply to Thread