Beta 1.7.3 doesn't have the same uniform sidedness that modern Minecraft does. It doesn't run a dummy local server in singleplayer. This can be jarring if you've become used to writing exclusively serverside code with the expectation that it will also work in singleplayer for free.
BTA might change netcode in the future, but as of 7.1-pre1a, you essentially have 3 sides to consider:
| side | PlayerController | EntityPlayer | World |
|---|---|---|---|
| SP client | client.player.controller.PlayerControllerSP extends client.player.controller.PlayerController | client.entity.player.EntityPlayerSP extends core.entity.player.EntityPlayer | core.world.World |
| MP client | client.player.controller.PlayerControllerMP extends client.player.controller.PlayerController | client.entity.player.EntityClientPlayerMP extends client.entity.player.EntityPlayerSP | client.world.WorldClient extends core.world.World |
| MP server | server.world.PlayerController | server.entity.player.EntityPlayerMP extends core.entity.player.EntityPlayer | server.world.WorldServer extends core.world.World |
Additionally, MP client tracks other players as client.entity.player.EntityOtherPlayerMP extends core.entity.player.EntityPlayer, and multi-dimensioned servers can encounter server.world.WorldServerMulti extends server.world.WorldServer.
Some of your code intended for SP might run in an MP client context. This can end up desyncing your locally replicated state. Make sure this case never occurs or include instanceof guards.
In the case of serverside mods that don't have a cooperating modded clientside ("server plugins"), you need to be wary of predictive replication done by the MP client. When I was writing the cursor code for bunyedit, cancelling block breaks on the server resulted in erronously ghosted blocks on the client. You need to alert the client that their prediction was false, in this case by immediately sending back Packet53BlockChange on the ghosted block.