Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12590 Discussions

sockets & not-accepting SYN packet breaks SELECT

Altera_Forum
Honored Contributor II
1,026 Views

Hi there,  

 

I'm using altera iniche TCP stack and I experience weird (imho) behaviour when I do not accept a connection using 'accept' function. 

 

My design is set such, that (as in simple socket server) I'm using select to wait for input stream to be ready. The select is using timeout (see [1]) and when timeouted, I just close the inactive channel. 

 

The first connection I accept, but all consecutive connections I want to refuse. So as TCPIP does not have 'refuse', it means that when I get SYN packet, I just drop it. In the 'simple socket server' they just don't do anything if they receive such request. 

 

So I tried it as well, but in my case it does not work. What happens is, that I do not react on the SYN, but since then, all consecutive calls to 'select' are immediately returned claiming, that the read file descriptor is ready to provide data. It almost looks like the SYN packet was not 'consumed', and the whole this thing starts to refuse any other attempt to connect, even if I kill due to timeout the original only connected socket.... 

 

does anyone experience the same problem?  

 

i wonder how the 'not-accepted' SYN packet should be treated to make 'select' working as usual, i.e. react only when new data arrive. some buffer flushes? 

 

[1] is modified to 'accept and close' the connection when new SYN packet arrives. This somehow work, but apparently there are some data in the read buffer as then the system enters many times into data processing cycle before the select starts to work again... 

 

[1] http://svnweb.cern.ch/world/wsvn/fbctdidt/trunk/vhdl/didt_nios_applications/didt_nios/sources/didt_server.c
0 Kudos
1 Reply
Altera_Forum
Honored Contributor II
338 Views

To comment on this: so far I have not found a rock-solid solution. Except that I accept the connection and then immediately close it. This surprisingly generates a lot of 'data transfers' with zero size: i.e. select command returns immediately showing that there is something on _data_ socket coming and when I try to read it, it has zero size. 

 

In any case if I ignore this behaviour, it seems to be stable for an amount of time (>2hours) and then it is killed with 'no free buffers for rx'. So I guess something stays on the stack... 

 

will continue investigaion
0 Kudos
Reply