On Oct 9, 10:55 am, Markus <markus.hofm...@gmail.com> wrote:
> You are right. The IP packet knows to my surprise which kind of data
> are transported. I was thinking that the IP header has no information
> about it.
>
> My other question I still have problems because I was thinking that on
> the application layer for example only HTTP data are received. The IP
> and port and the transport kind (TCP/UDP/ICMP) are removed. But there
> must be still a problem in my logic.


That's not quite right. The protocol type field in the IP header is
used to determine to which upper level layer the packet should be
kicked to. The upper layer still can see the source and destination
IP addresses. In addition, if the upper layer has a concept of a port
(like TCP and UDP do), the port number is part of the TCP (or UDP)
header, and *not* part of the IP header.

Anyway, a single TCP session is defined by all four of those items -
the source and destination IP addresses, plus the source and
destination ports. So if you had two browsers requesting a page from
a given server, you'd have identical source and destination IP
addresses, the remote port would be 80 for both sessions, but the
local port would be different. Because these are outgoing sessions,
you'd generally get a randomly assigned ephemeral port (usually above
1024 for many *nix system , above 49152 for many others) for the local
side. Note that you have to keep track of which way a packet is
going, and swap the source and destination addresses and ports
appropriately.

So if your PC has IP address 1.2.3.4 and the web server 2.3.4.5, your
two sessions might be defined by the following tuples:

IE: local:1.2.3.4/5001, remote:2.3.4.5/80
FF: local:1.2.3.4/5002, remote:2.3.4.5/80

Note how the local ports are different.

Somehow the OS binds all that that to some application addressable
item, typical a handle to a socket or something like that.