A successful race attack is one where the payment recipient's node receives a spend transaction yet the next block that is mined has a different transaction that spends the same coin. Thus the payment recipient's transaction will not confirm and the recipient never receives the funds.
This is an explicit attack to double spend. The recommended protection is to not accept payment on 0/unconfirmed if there is no recourse (e.g., an anonymous buyer who makes off with the item traded before the double spend can be detected.) For some types of businesses (e.g., retail, low-value goods purchased in-person, face-to-face), the risk is acceptable.
The recommendation for the merchant is to disable listening on the client (using -nolisten) and to explicitly connect to a well connected node (using -connect= ).
How does a merchant know which nodes are well-connected. Because pool mining solves over half the blocks, ideally the well-connected node is one that reaches these pools first, so that if a transaction is relayed by the well-connected node then the odds are it will end up being the transaction mined by a pool even if there was an attempted double-spend.
Are there any nodes that are known to be good for relaying transactions to the pools, and thus preventing a race attack from being successful?