Chain Race: How to know chain-length of competing chain? If a fork happens, miners mine on the block they receive at first.
Further, they only forward the block they received first (so the block they will use to mine)!

So it can happen that 10% of the network will mine on the chain A. The other 90% will mine on chain B. So only 10% know about chain A and 90% know about chain B. And some edge node will know about chain A and chain B... Depends on how the overlay structure looks like.

What happens if now the 10% fork (chain A) will mine a block and send it to the network? Why won't the other nodes discard the block from chain A? How do they know that this chain is longer? How do they know that the block is not just some part of DDOS attack?

If someone could give me a detailed describtion how the conflict is solved, I would be very happy.
What happens if now the 10% fork (chain A) will mine a block and send it to the network?


When a miner building on top of chain A finds a valid block, it will relay the block to the rest of the network. For convention let us assume the fork (chain A and chain B) has happened at block height N. This is how different nodes on the network will react when they receive a block at height N+1 whose parent is on chain A.


Nodes already using chain A: For them, this block N + 1 is a natural progression of the blockchain and as a result they will just add this block to their blockchain.
Nodes using chain B but has chain A block: There might be some nodes who might have received the chain A block at height N after receiving block at height N from chain B. Since these node received block from chain B first, they will use this version of the chain as their primary one. However, block from chain A that is received later is not discarded but is processed and kept on the disk. So, when block at height N + 1 is received from chain A version, these nodes just revert the chain at height N and use the other block that was kept on disk.
Nodes only having chain B: When they receive block at height N+1 from chain A, these nodes will see that they do not have its parent. As a result, these nodes will query the parent block using the previousblockhash and see if it exists. The nodes having this block will then transmit that block to the nodes not having it. When that block is received, these nodes will see that this chain is the longest proof of work chain and as a result they will now operate on chain A. The block at height N from chain B becomes stale but it is not discarded and is still kept on disk.



  How do they know that this chain is longer?


Nodes accept the longest proof of work chain (in most cases it is same as the longest chain). Nodes sync headers first and verify the proof of work of the chain before asking the actual blocks from other nodes. When nodes on chain B version of chain receive the header of block N+1 on chain A version, they will see that the chainwork of the block received is more than that of the chain they already have and as a result will use it to query the block associated with it.


  How do they know that the block is not just some part of DDoS attack?


When they receive the block header, the proof of work is verified first. So, if the attacker wants to spam the network with invalid blocks, he/she would have to do so with valid proof of work. That means spending immense amount of energy as other miners but not getting the reward (as the block does not have any ancestor, it will be rejected). If the node receives a block header with invalid proof of work, then the node that has sent this block header will be blacklisted after certain attempts of this mischief. This was actually the basis of PoW in 1990s when it was used to prevent spam emails.