sockets & not-accepting SYN packet breaks SELECT

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