data through a network ???

[Ghost0s]

IF we send a huge different type of data(image,videos and music) for example through a network it will physically represented as bits 10101010 the question is how the device that will receive the data will know the bits that represent each type or lets say how it will decrypt that

[L7Sqr]

The device doesn't care. The device handles frames (google for Ethernet protocol) which have mechanisms for synchronisation and consistency.

A device is simply handed a frame (from some upper layer protocol, for example) and sends that frame out. On the receiving side, that frame is received and handed up (to some upper layer protocol).

An example may be helpful. Suppose two applications are sending data from host A to host B. One type is sending UDP video, the other is sending TCP file transfer (ftp). Let's say, for simplicity, that the two are sending at the same rate and the packets are interleaved.
The outbound process looks something like:

1) App1 (create [data])       App2 (create [data])
2) [UDP|data]                 [TCP|data]]
3) [IP|UDP|data]              [IP|TCP|data]
4) [ETH|UDP|data]             [ETH|IP|TCP|data]
                  (Device queue)
                [ETH|IP|TCP|data]
                [ETH|IP|UDP|data]
                [ETH|IP|TCP|data]
                [ETH|IP|UDP|data]               
                      ...
                    Send bits
                       |
                       |
                       V

The notation of [IP|UDP|data] represents a packet of data that is an IP packet containing a UDP packet which contains some data. You can see that, as you move down the layered stack, you encapsulate data so that you don't have to worry what the data is - you only care about your layer.

The sending device has no idea whether it is sending UDP, TCP, video, ftp, or whatever.

On the receive side, that process is reversed.

          |
          |
          V
       Recv bits
    [ETH|?????????]

1) Parse Ethernet header to determine encapsulated type
2) Now we know next type, strip outer Ethernet header
     [IP|????????]

3) Parse IP header to determine encapsulated type
4) Now we know next type, strip outer IP header
       [UDP|????]

5) Parse UDP header to determine port assignment)
6) Strip outer UDP header and deliver data to end application

Notice that until step 5, the end application is not known. Step 1 (where you are concerned) knows nothing more than an Ethernet frame has been received. At each step a decision is made on how to handle the packet by parsing the next layer of the packet.

This is why the layered design of the network stack is such an effective approach to sending arbitrary data over the network.

[Ghost0s]

so there is some headers and ending points that marks the beginning and the ending of some kind of data ??

[taichichuan]

If you're sending this with TCP sockets, the data will be converted to a stream of bytes and stuffed into the packet to be sent. There are no delimiters placed into the stream by the protocol. And, there's no guarrantee that you will get full MTU transfers (the Nagle algorithm might get in your way). So, if you do a write(fd, buf, 2048) (assuming there were 2048 bytes in the buffer at address buf), there's really know way to know how the packets will be delivered. However, you do know that they will be delivered in the order they were sent and they will get there eventually.

So, on the receiver side, you simply continue to read from the socket until you have the same number of bytes that you sent on the sender's side. This is the technique if you have fixed record lengths. If you have variable record lengths, then you'll need a fixed size message header that describes the size of the message, followed by the message itself. Read and decode the header and then read that number of bytes to get the enitre message.