Recently, I have been working on a project using Alfresco JLAN to simulate a Windows CIFS (aka Samba) share in Java. Not being able to (easily) replace the entire Windows file sharing stack, it instead advertises its virtual host name via a Win32 API call to the NetBIOS Naming Service.
From the NetBIOS Wikipedia entry:
In NetBIOS, each participant must register on the network using a unique name of at most 16 characters. In legacy networks, when a new application wanted to register a name, it had to broadcast a message saying "Is anyone currently using that name?" and wait for an answer. If no answer came back, it was safe to assume that the name was not in use. However, the wait timeout was a few seconds, making the name registration a very lengthy process, as the only way of knowing that a name was not registered was to not receive any answer.
When attempting to roll it out to production, we ran into an interesting issue. Unlike our QA system, production has multiple IP subnets. When the NetBIOS broadcast goes out, it only gets broadcast to the local subnet. As a result, only systems on that subnet can address it by name. We actually broke out Wireshark on both the server and the client side to verify that yes, indeed, the broadcasts were not seen on the remote subnet(s):
This actually makes perfect sense, but not being involved in the day-to-day networking in the office, it took me a while to see why. One of the purposes of the subnets is to reduce broadcast traffic; allowing an overly chatty network can lead to congestion. And while there are router-level solutions to let certain broadcasts cross subnets, those are something of a maintenance nightmare.
A simple solution turned out to be the Windows lmhosts file. It works like the regular hosts file, but ties NetBIOS (versus DNS) names to IP addresses. By manually configuring the mapping in this file on the client(s), we can side-step the whole broadcast/subnet issue. Just remember to rename the file from lmhosts.sam to just lhmosts.