Hi everybody,

I have an understanding problem of how a TCP/IP stack works.

After the IP data where processed and the IP header is removed, the
data packet could be TCP, UDP, or ICMP. At the moment I do not
understand how and where the decission is made. For example if the
data are TCP the message need an acknowledgement.

The same understanding problem I have with the application layer. If I
have running two programs like Firefox or IE where the stack knows
which browser invoked which homepage?

Thank you in advance.

Markus

I'll give it a go.

The ip header contains a protocol field which specifies which other protocol
is on top of it.

This is used to pass the protocol on top to it's module/section of code
which handles it.

Address+Port+Socket or something like that indicates which
computer/application it belongs too.

Sometimes applications can share address+port, so then the socket probably
makes the difference as well.

Think multicast and broadcast.

Bye,
Skybuck.

Hi Skybuck,

"The ip header contains a protocol field which specifies which other
protocol
is on top of it."

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.

Thanks,
Markus

On Oct 9, 11:55 am, Markus <markus.hofm...@gmail.com> wrote:
> Hi Skybuck,
>
> "The ip header contains a protocol field which specifies which other
> protocol
> is on top of it."
>
> 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.

The application needs to keep track of each session, which it does
with a combination of source and destination IP address, source and
destination port IDs, protocol ID, and other identifying unique
numbers, such as the "Identifier" in ICMP Ping, for instance.

Bert

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.

<snip>

> 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.

You are correct, applications which use the winsock api (which is an api to
work with/access the tcp/ip stack) usually removes ip/tcp/udp headers and
that sort of thing and only returns http protocol headers/content.

Special http protocol libraries might even remove some of the http stuff...
and just return some text or so.

Bye,
Skybuck.

On Oct 10, 10:55 am, "Skybuck Flying" <s...@hotmail.com> wrote:
> <snip>
>
> > 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.
>
> You are correct, applications which use the winsock api (which is an api to
> work with/access the tcp/ip stack) usually removes ip/tcp/udp headers and
> that sort of thing and only returns http protocol headers/content.
>

That's not 100% correct. The socket API (winsock etc) only removes
data from the IP and TCP headers from the data stream. Most of that
information is still available to the application using other
functions in the sockets API. Think of the socket API as a convenient
unwrapper which stuffs things it understands into structs you can
query and dumps things it doesn't understand (it's payload) to recv()
to be handled by the application.

In article <1191945317.598746.14580@57g2000hsv.googlegroups.c om>,
Markus <markus.hofmann@gmail.com> wrote:

> 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.

When you create and bind a socket you specify the transport protocol and
the port number that it should use, or you can let the stack find an
unused port number (you can use getsockname() to find out what it
chose). These aren't returned because they're implicit in which socket
the data is received on.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Hi @all,

first thanks for your answers.

The entry which make it more clean that the modell in my mind is to
easy was the example of Robert. If an application will send data over
TCP/IP stack it must determine which transport kind (TCP/UDP/ICMP)
will be used, it must set the source and destination port and it must
inform the IP layer the source IP and destination IP. With other words
the lower layer must be "configured". On the receiving side it must be
the same. Otherwise the application layer can not figure out if the
data are for this application. I do not know how I came yesterday to
the conclusion that this is done automatically. *lol*

Regards,
Markus

Yes some information can be retrieved via the api.

For example the api returns ip address and port on which payload was
received, and how many bytes.

Bye,
Skybuck.

On Oct 9, 8:45 am, Markus <markus.hofm...@gmail.com> wrote:
> Hi everybody,
>
> I have an understanding problem of how a TCP/IP stack works.
>
> After the IP data where processed and the IP header is removed, the
> data packet could be TCP, UDP, or ICMP. At the moment I do not
> understand how and where the decission is made. For example if the
> data are TCP the message need an acknowledgement.
>
> The same understanding problem I have with the application layer. If I
> have running two programs like Firefox or IE where the stack knows
> which browser invoked which homepage?

The following link should . You will find TCP/IP sequence diagrams
that should answer some of your questions.

http://www.eventhelix.com/RealtimeMantra/Networking/

--
VisualEther - http://www.EventHelix.com/VisualEther
Generate sequence diagram from Wireshark (Ethereal)

"Markus" <markus.hofmann@gmail.com> wrote in message
news:1191933925.663848.151130@g4g2000hsf.googlegro ups.com...
> Hi everybody,
>
> I have an understanding problem of how a TCP/IP stack works.
>
> After the IP data where processed and the IP header is removed, the
> data packet could be TCP, UDP, or ICMP. At the moment I do not
> understand how and where the decission is made. For example if the
> data are TCP the message need an acknowledgement.

The IP header has a protocol TCP = 6, UDP = 17. Get yourself a copy of
ethereal and you can see how this stuff works by capturing packets.

> The same understanding problem I have with the application layer. If I
> have running two programs like Firefox or IE where the stack knows
> which browser invoked which homepage?

The incoming port number is the main discriminator as it is tied to the
specific socket. All applications create a socket before communicating.