Chronological Thread 

< Chronological >      < Thread >

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Dienstag, 22. Oktober 2002 07:33 schrieb Oon Heok Kee:
> Hi Thomas,
>
> Thank you very much for your help. I have gone through what you have
> suggested, but we still met with some problems which my tutor and I can't
> solve. I've given a more complete piece of the code, including your
> suggestion, hope that you can enlighten us. The problem is still the same;
> ext_getsockopt() returns a 0.

SO_RCVBUF and SO_SNDBUF get or set the values maxSendQueue and maxRecvQueue
in the SCTP_Association_Status structure. The socket API already supports it,
but not the sctplib. I had a look into sctp.h and found the following:
/** currently unused */
unsigned int maxRecvQueue;
Setting the receiver queue currently has no effect (see distribution.c),
getting this value always returns 0. A limitation of this queue may be
implemented in a later version of the sctplib.

Note, that setting or getting the size of the send queue is already possible;
although sctp.h comments state that it is currently unused. But i found a
small bug preventing ext_setsockopt() from setting it. Go to ext_setsockopt()
in sctpsocketwrapper.cc and move the "case SO_SNDRCV:" block from the
IPPROTO_SCTP block to the SOL_SOCKET block and it will work. I have attached
the corrected version of the file for socketapi-1.0.0 (gzip-compressed).
Within the next few
days, I will release bugfix release version 1.0.1 of the socket API
correcting this and another bug.


> I've set the number of chunks as just 7, and the results are still the
> same. Everytime ext_getsockopt() is called, it returns a 0 (because it
> always prints "ipv4 warning: socket buffer size is 0x0 instead of
> 0x80000").
>
> The i_handle that was spawned from ext_socket() has the value 1023,
> which looks rather suspicious. It there anything wrong with this? In the
> later part of the (unworking) program, we are experiencing a "Bad file
> descriptor" error, so we're wondering if this could be the cause of it.

No, the socket API has its own socket numbering. I implemented numbering from
FD_SETSIZE-1 (=1023) down to 1 to make it easier to find errors of missing
"ext_" prefix. For example, if you use socket() instead of ext_socket(), you
get a low FD number (e.g. 5). Printing it as debug output, you almost
directly see that the "ext_" is missing. Using ext_socket() instead results
in returning a higher value (e.g. 1020).
FD_SETSIZE

>
> Once again, thank you for your help!!
>
>
>
> Oon, Heok Kee
>
>
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> int i_handle, i_opt, i_opt_size, result;
> struct sockaddr_in sock;
>
> /* i_handle always returns 1023. */
> if( (i_handle = ext_socket( AF_INET, SOCK_STREAM, IPPROTO_SCTP)) == -1 )
> {
> intf_ErrMsg( "ipv4 error: cannot create socket (%s)", strerror(errno) );
> return( -1 );
> }
>
> /* ext_connect() has no problem, returning a 0. */
> if((result = ext_connect(i_handle, (struct sockaddr *) &sock,
> sizeof(sock))) == (-1))
> {
> intf_ErrMsg( "ipv4 error: cannot connect socket (%s)", strerror(errno)
> ); ext_close( i_handle );
> return( -1 );
> }
>
> if(result == 0)
> {
> /* ext_setsockopt() != -1, so I think it's ok (at least not giving
> problem). */
> i_opt = 7;
> if(ext_setsockopt(i_handle, SOL_SOCKET, SO_RCVBUF, (void *)&i_opt,
> sizeof(i_opt)) == -1)
> {
> intf_WarnMsg( 1, "ipv4 warning: cannot configure socket (SO_RCVBUF:
> %s)", strerror(errno));
> }
>
> /* ext_getsockopt() is returning 0, but value of i_opt is also returned as
> 0! */
> i_opt = 1;
> i_opt_size = sizeof(i_opt);
> if(ext_getsockopt(i_handle, SOL_SOCKET, SO_RCVBUF, (void*)&i_opt,
> &i_opt_size) == -1)
> {
> intf_WarnMsg( 1, "ipv4 warning: cannot query socket (SO_RCVBUF:
> %s)", strerror(errno));
> }
> else if( i_opt < 0x80000 )
> {
> intf_WarnMsg( 1, "ipv4 warning: socket buffer size is 0x%x"
> " instead of 0x%x", i_opt, 0x80000 );
> }
> else printf(" Socket successfully connected\n");
> }
>
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@


Best regards
- --
=======================================================================
Dipl.-Inform. Thomas Dreibholz

University of Essen, Room ES210
Inst. for Experimental Mathematics Ellernstraße 29
Computer Networking Technology Group D-45326 Essen/Germany
- -----------------------------------------------------------------------
E-Mail:
dreibh AT exp-math.uni-essen.de
Homepage: http://www.exp-math.uni-essen.de/~dreibh
=======================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9tRA932BbsHYPLWURAnHzAJsEB5OpgJS3ULFpTqNeYZ7noha2jgCgt46S
VnzUkA5Z7IUXSqLMY9FNYM4=
=55Pp
-----END PGP SIGNATURE-----

Attachment: sctpsocketwrapper.cc.gz
Description: GNU Zip compressed data

---

• [SCTP-Discussion] ext_getsockopt and ext_setsockopt problems, Oon Heok Kee, 10/21/2002
  • Re: [SCTP-Discussion] ext_getsockopt and ext_setsockopt problems, Thomas Dreibholz, 10/21/2002
  • <Possible follow-up(s)>
  • Re: [SCTP-Discussion] ext_getsockopt and ext_setsockopt problems, Thomas Dreibholz, 10/21/2002
  • Re: [SCTP-Discussion] ext_getsockopt and ext_setsockopt problems, Thomas Dreibholz, 10/22/2002
  • Re: [SCTP-Discussion] ext_getsockopt and ext_setsockopt problems, Thomas Dreibholz, 10/22/2002

---

Archive powered by MHonArc 2.6.19+.