Client behavior is just what it sounds like. It is the behavior exhibited by a client using your application, server, service, etc. This cannot be controlled in any way since you have no presence on the system beyond the application or service used by the client. Most of the time this isn't an issue, but occasionally presents itself as a problem to solve form the server/application side.
During testing, we found that a Windows client that we used for mounting SMB shares would cache the share connection information even after the share was disconnected using something like 'net use /d.' But how did we figure this out? While getting a packet capture, we mounted a share to the Windows client, disconnected it, and then reconnected a few minutes later. The session information for the multiple mapping attempts were the same. After looking into it more, it turns out that a Windows client's Explorer.exe process will cache the connection information when shares are mapped. We have not been able to figure out when this cache is cleared, but since we use automation to perform testing, we can't afford to wait minutes or hours for the cache to clear to ensure new session information.
So, after a few talks about 'client behavior' I found a method of preventing this kind of 'convenience' from impeding our testing efforts. I present to you, the fix:
taskkill /IM explorer.exe /F; explorer.exe
