source code for tcp/ip stack

[sandy]

hello can anbody help me in getting source code for tcp/ip stack in
ANSI C or source code for http protocol

 

[Vladimir Oka]

sandy opined:

hello can anbody help me in getting source code for tcp/ip stack in
ANSI C or source code for http protocol

What's wrong with Google? You used it to post this.

 

[Walter Roberson]

sandy opined:

What's wrong with Google? You used it to post this.

It would take rather a lot of googling to find source code for
a TCP/IP stack written in standard ANSI C, as the C standards
know nothing about the existance of networks. Any TCP/IP stack
would have to contain operating-system specific calls
that are beyond the scope of the C standards.

In order to write a TCP/IP stack, at the very minimum one
needs to have a routine to accept a packet from hardware,
and another to dispatch an arbitrary packet towards hardware.
Such low-level calls are not available even in POSIX.1.


Source code for the http protocol is also problematic, but for
a different reason: a -protocol- is not the same thing as
an -implementation- of the protocol. There are many implementations
available (such as Apache) -- none of which can be written purely
in standard C though.

 

[Richard Tobin]

In order to write a TCP/IP stack, at the very minimum one
needs to have a routine to accept a packet from hardware,
and another to dispatch an arbitrary packet towards hardware.
Such low-level calls are not available even in POSIX.1.

That's not much of a problem, since a couple of calls to functions
defined elsewhere doesn't affect the standard-C-ness of the stack
itself. A more serious problem is that a real implementation is
likely to use virtual memory tricks to avoid copying data, and will be
designed to fit into some particular operating system.

-- Richard

 

[Walter Roberson]

That's not much of a problem, since a couple of calls to functions
defined elsewhere doesn't affect the standard-C-ness of the stack
itself.

For the purposes of this newsgroup, the only ANSI C programs
are those for which all the source could {theoretically} be examined
and found not to use any extensions or constructs or system calls
not documented as the ANSI/ISO standards as existing.

I suppose in theory one -could- have an OS in which packetization
was accomplished by fopen()/fclose() on a magic filename -- the result
wouldn't be much portable, but the code could be ANSI C. Failing
that, ANSI C does not provide any method to signal the end of a packet
within a stream. To stay entirely within ANSI C would then require
use of features documented as implementation-defined -- in particular,
of converting an integral value to a pointer and dereferencing
in order to access memory-mapped hardware. That would be ANSI C, but
not portable... I suppose you just -might- find source for such a
thing via google, if you looked long enough (or knew exactly what
you were looking for.)

A more serious problem is that a real implementation is
likely to use virtual memory tricks to avoid copying data, and will be
designed to fit into some particular operating system.

But virtual memory tricks are inherently tricks with memory-mapped
locations, so the integer -> pointer conversion would have a better
chance of being meaningful ;-)

 

[Ian Collins]

That's not much of a problem, since a couple of calls to functions
defined elsewhere doesn't affect the standard-C-ness of the stack
itself. A more serious problem is that a real implementation is
likely to use virtual memory tricks to avoid copying data, and will be
designed to fit into some particular operating system.

There are several "tiny" IP stacks out there designed for 8 bit embedded
use that should meet the OP's requirements. I haven't trawled the
source for ANSI compatibility, but these stacks are designed for
portability.

Spend some time with Mr. Google.

 

[Walter Roberson]

There are several "tiny" IP stacks out there designed for 8 bit embedded
use that should meet the OP's requirements. I haven't trawled the
source for ANSI compatibility, but these stacks are designed for
portability.

The uIP stack is one example,
http://www.sics.se/~adam/uip/

It is fairly cleanly written, but if one digs down far enough,
it relies upon the "tapdev" device driver which is written
in terms of ioctl(). The non-portable portion is certainly
isolated, but it's still non-portable.

 

[Ian Collins]

The uIP stack is one example,
http://www.sics.se/~adam/uip/

It is fairly cleanly written, but if one digs down far enough,
it relies upon the "tapdev" device driver which is written
in terms of ioctl(). The non-portable portion is certainly
isolated, but it's still non-portable.

True, you will hit the hardware or OS at some point, but as a stack,
this is a good, clean example.