Problem on TCP server with Accept API

Hi Kartheek,

Please explicitly set the optval argument to SOCK_ON for optname SOCKOPT_ACCEPT_NONBLOCK.

int optVal = SOCK_ON.
setsockopt(sock, SOL_SOCKET, SOCKOPT_ACCEPT_NONBLOCK, &optVal, sizeof (optVal));

This should make your accept non-blocking, and should return -2. Commenting a previous blocking setsockopt will not make is non-blocking.

Thanks & Regards,

Raghavendra

Hi Raghavendra,

Thanks For your reply. I will check it. For the non-blocking accept is it require to call this function every time?

Thanks,

Kartheek.

Hi Kartheek,

You would need to call it everytime after you set it for blocking operations.

Thanks & Regards,

Raghavendra

Hi Raghavendra,

This SetSockopt function is returning the value -1, So that still accept function is blocking.

Thanks,

Kartheek  

Hi,

Does the accept break after sometime? Or does it return immediately? Can you please check if the accept returns after time 'aucInactivity' passed to 'netapp_timeout_values'?

Thanks & Regards,

Raghavendra

Hi,

After client is connected to the server only accept function is exiting. I tried with option SOCK_ON, But setsockopt returning -1 always. But this is happening immediately.

Thanks,

Kartheek. 

What's the value of sizeof(optVal) ?

Also, the comments (!) state

//! @Note On this version the following two socket options are enabled:

//! The only protocol level supported in this version

//! is SOL_SOCKET (level).

//! 1. SOCKOPT_RECV_TIMEOUT (optname)

//! SOCKOPT_RECV_TIMEOUT configures recv and recvfrom timeout

//! in milliseconds.

//! In that case optval should be pointer to UINT32.

//! 2. SOCKOPT_NONBLOCK (optname). sets the socket non-blocking mode on

//! or off.

//! In that case optval should be SOCK_ON or SOCK_OFF (optval).

but the header defines other commands:

#define SOCKOPT_RECV_NONBLOCK 0 // recv non block mode, set SOCK_ON or SOCK_OFF (default block mode)

#define SOCKOPT_RECV_TIMEOUT 1 // optname to configure recv and recvfromtimeout

#define SOCKOPT_ACCEPT_NONBLOCK 2 // accept non block mode, set SOCK_ON or SOCK_OFF (default block mode)

there is no SOCKOPT_NONBLOCK value defined!

Hi Anthony,

Thanks for pointing it out. We will correct the comments section when we make our next host driver release.

The Opt name SOCKOPT_NONBLOCK is not used anymore. Instead, we use SOCKOPT_RECV_NONBLOCK and SOCKOPT_ACCEPT_NONBLOCK in our latest release.

The sizeof(optval) is the length of opt that you pass in the 4th argument. It need not be sizeof(optval) in all the cases, it is implementation dependant.

Thanks & Regards,
Raghavendra

So what is the size I should pass in when passing SOCK_ON?

I'm trying to set up the socket for non-blocking accept, and keep getting -1 back as did the above poster.

I've tried setting the option at every point after each of these calls

socket

bind

listen

but it still fails each time.

The socket handle I'm being returned from socket is 0.

Hi Anthony,

The best way would be to pass the size of the variable that is holding SOCK_ON as its value. As I have mentioned above, pass sizeof(OptVal).

When you are accepting in a non-blocking mode, you should get a return value of -2 for setsockopt.

There could be a mismatch with the host driver and the service pack version. Can you please confim their versions? With the host driver v1.12, you should be using the service pack version 1.26.

The socket handle of 0 looks fine. Please use setsockopt for opt name SOCKOPT_ACCEPT_NONBLOCK only once after you finish the call to listen.

Thanks & Regards,
Raghavendra

We have patched the firmware to 1.26

We are writing our own driver, based on 1.12, as we need to have it not block.

sizeof(OptVal) in your case is an int, but that is platform dependent.

Can the api really handle any size argument for SOCK_ON and SOCKOPT_ACCEPT_NONBLOCK?

What is the byte ordering for the argument?

Actually, the hoster_driver_version.h says 15 whatever that means.

I've found my bug.  Unfortunately, I was passing a couple extra bytes at the beginning of the structure.

However, my size and byte order questions remain.

Also, SOL_SOCKET is defined as 0xFFFF but copied into a 32 bit int in the message.  Is it sign extended?

So, the 5 bytes of payload I'm getting from setsockopt are:

00 63 7b 08 00

That doesn't look like -2.

Hi Anthony,

Sorry about that mistake. It's the accept that should return -2, and not the setsockopt.

The driver takes care of the byte ordering and it has to be little endian.

The SOL_SOCKET is not signed extended. It is just maintained as a 32 bit value like the other parameters.

Thanks & Regards,
Raghavendra

There's a stack overflow question about using select to determine if it's safe to call accept here:

http://stackoverflow.com/questions/3444729/using-accept-and-select-at-the-same-time

Will a select on the readfs indicate the socket can have accept called on it in the TI implementation?

After more hours wasted, it appears that select does not mark the readfs as ready when the socket is in the listen state, and could accept a connetion.  is that a bug, or by design?

Hi Anthony,

I don't think select supports marking of the readfs for an incoming connection request. I will have a look at this.

Thanks & Regards,
Raghavendra

This thread seems to state that your implementation doesn't support using select to detect if a socket is ready: