> You should break the current ClientProtocol into AdminProtocol and the real ClientProtocol
We can certainly do this. The ClientProtocol essentially consists methods that fall into two categories:
1. Calls that modify file system metadata in the namenode
2. Calls that retrieve portions of file system metadata from the namenode.
Let's consider the case when the NN is restarting and is in safemode. Only the servicePort is open at this time. The calls in category 1 will anyway fail because namenode is in safemode. That leaves us with only the calls in category 2. When the namenode is in safemode, the admin would still want the ability to be able to list files (dfs -lsr) , get status on files (dfs -ls), see the amount of space used by a portion of the namespace (dfs -count), validate block size of an existing file(s), look at target of a symlink. That means that admin would want to invoke most of the calls in category 2, isn't it? If you agree with the above, then it is not very beneficial to break up ClientProtocol into two parts, because both the parts would have to be available on the service port?
There are quite a few things that we can do to handle "a mis-configured client happens to choose the service port as its client port". if we do not even list the service port in the client's config, that would be a good thing.... can we start there?