I've been working on a client/server application and recently found that things didn't work so well if our client is a mac running 10.4. This is fairly technical, so I'm not sure if someone can help, but basically what is happening is that when the client (mac) closes the connection, it sends the FIN, then the host recieves it, enters the LAST_ACK state, then awaits the ACK from the client. The problem is, the client never sends the ack, and the host gets stuck in this state. Does anyone know what may be causing this? Every other OS we have tried this on (OS X 10.3, XP, 98, 2k, various Linux flavors) all send the last ACK, but 10.4 doesn't.

This isn't an issue with your client. It is an issue with the server. It could be the way in which the client is disconnecting if it happens everytime, but the LAST_ACK hang is a known linux kernel issue, I suggest upgrading your linux kernel to the latest version possible. The LAST_ACK state is normal, but it hangs because of a misconfiguration in the socket library.

Except they aren't using a linux kernel since the problem is with OSX 10.4, which uses a XNU kernel.. http://www.kernelthread.com/mac/osx/arch_xnu.html

OSX is the client, wyled was talking about the server.

Well, it is probably possible to squash the problem client-side, but server-side is much more practical... especially if you are massively distributing this client to a wide variety of computers. If the server is on a linux server (which i'm assuming it is) you just need to upgrade your kernel and gcc packages. This should help at least reduce the LAST_ACK length (I have seen it last for hours - I believe this was on a Fedora core 3 server). Like on my server when I get LAST_ACKs they last for a maximum of 5 minutes or so. However, a LAST_ACK shouldn't really matter if you have built your server appropriately (eg. you should never be closing your listener socket except on rebooting your server program - thus the LAST_ACK doesn't pose a problem).

Actually the server is a microcontroller with very limited TCP support. Thus, this isn't the first problem like this we have found.

It does seem that there will be a memory leak when the socket get's put in the LASK_ACK state, and then never receives the final ACK from the client. We just found it wierd because Mac OS X 10.4 is the only client we have seen that closes (or rather doesn't close) sockets in this way. I know it's something I can fix in the firmware, but currently the issue is trying to replicate this issue (I dont' have access to a 10.4 machine right now).

Does anyone know why the client closes sockets in this way? Is it something that windows and most Linux flavors will do in the future? Is this like a not standard way of doing things, but follows the standard and is more efficient kind of thing or a this makes more sense and new software will likely do this kind of thing?

It's mostly a problem because of the limited memory space we have. Each time a client connects the socket structure is created. We have room for about 4 of those sockets. The way things are now, they don't get free'd until that last ack comes from the client. I'm sure I can write the code to change that, so it is freed, but right now without being able to replicate the problem it'd be hard to test and make sure it's fixed.

Is there maybe a way to turn that feature on in a Linux enviroment? So we can use that as the client and not send the last ACK?

[Edited by - DrjonesDW3d on January 25, 2006 5:09:48 PM]

Bumping this thread up because it is of interest to me. DrjonesDW3d have you been able to solve it?