TCP socket accept() returns on [SYN] on windows server 2012

Question

I use HAProxy which sends health check every 10 seconds.

It goes in the following fashion:

HAProxy -> server: [SYN]
server-> HAProxy : [SYN, ACK]
HAProxy->server  : [RST, ACK]

My TCP server is written in java in the following way:

while (true){
    Socket socket = kaServerSocket.accept();
    MyListener listener = new MyListener(socket);
    listener.start(); //costly operation
}

On windows 7, accept() does not return after this exchange (it returns after the regular syn->ack->syn handshake), and that's what I need.

However, when the application is running on Windows server 2012, accept() function returns on the first [SYN] which is sent from HAProxy, and performs the costly operation.

So I have 2 questions:

1. Is this behavior configurable?

2. If I don't want to wait for the first bit or message before I run the listener, how can I detect the connection is from HAProxy on windows 2012?

EDIT:

May it be connected to the ATM TCP/IP on Windows?

https://msdn.microsoft.com/en-us/library/windows/desktop/ms737526(v=vs.85).aspx

When using the accept function, realize that the function may return before connection establishment has traversed the entire distance between sender and receiver. This is because the accept function returns as soon as it receives a CONNECT ACK message; in ATM, a CONNECT ACK message is returned by the next switch in the path as soon as a CONNECT message is processed (rather than the CONNECT ACK being sent by the end node to which the connection is ultimately established). As such, applications should realize that if data is sent immediately following receipt of a CONNECT ACK message, data loss is possible, since the connection may not have been established all the way between sender and receiver.

Quite

Answer 1

See How does the socket API accept() function work?

From http://soft.vub.ac.be/~tvcutsem/distsys/sockets.pdf It seems like this is the expected behavior as HAproxy is opening the socket to the client in order to route it to the other machine.

The problem is that HAproxy is TCP compliant :)

A workaround should be to start doing your logic after some logic from the server was verified (for example, a small message was sent and an ACK was recieved though the socket).

Gilleod

Yes, we implemented a workaround of waiting for the first bit. But we're still not happy, cos a) we don't know if the TCP client (which is not implemented by us) will try to connect and wait silently before sending something. And b) hey, it works on windows 7! On win7 we had a perfect way of differing between the silent client which sent a normal triple handshake and then went silent, and HAproxy which sent syn-ack-rst trick just to check the port is open. That's a nice feature we'd like to take advantage of. – Quite