Why not networking support?

M

Mark A. Odell

Why doesn't the standard library provide (at least basic)
networking facilities using TCP/IP ?

What does that mean to an 8-bit microcontroller with 128 bytes of RAM and
8kB of ROM? C has been ported to all sorts of hardware, many that simply
could not easily fit even a simple TCP/IP stack. No, C should not be
burdened with networking.
 
H

H.A. Sujith

Why doesn't the standard library provide (at least basic)
networking facilities using TCP/IP ?
 
?

=?iso-8859-1?q?Nils_O=2E_Sel=E5sdal?=

What does that mean to an 8-bit microcontroller with 128 bytes of RAM and
8kB of ROM? C has been ported to all sorts of hardware, many that simply
could not easily fit even a simple TCP/IP stack. No, C should not be
burdened with networking.
Humm, file access wouldn't make much sense on such systems either..
Anyway original poster should rather turn to the posix specifications.
 
R

Richard Bos

H.A. Sujith said:
Why doesn't the standard library provide (at least basic)
networking facilities using TCP/IP ?

Because not nearly all networks are TCP/IP, and when C was first
standardised, even fewer were.

Richard
 
D

Dan Pop

In said:
Why doesn't the standard library provide (at least basic)
networking facilities using TCP/IP ?

Why TCP/IP?

Instead of trying to answer my question, think about it. It's supposed
to contain the answer to your question.

Dan
 
J

Joona I Palaste

Why TCP/IP?
Instead of trying to answer my question, think about it. It's supposed
to contain the answer to your question.

Umm... I know! I think. Can I answer for the OP?

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The day Microsoft makes something that doesn't suck is probably the day they
start making vacuum cleaners."
- Ernst Jan Plugge
 
M

Mark A. Odell

Umm... I know! I think. Can I answer for the OP?

Me too, I think because then someone would ask, "Why not DeviceNET" and
then we'd add that to C and next thing you know, C would only be able to
run on hosted implementations.
 
J

Joona I Palaste

Me too, I think because then someone would ask, "Why not DeviceNET" and
then we'd add that to C and next thing you know, C would only be able to
run on hosted implementations.

You are right, but that's not what I was thinking about. Maybe I read
too much into Dan's emphasis on _TCP/IP_?
 
M

Mark A. Odell

You are right, but that's not what I was thinking about. Maybe I read
too much into Dan's emphasis on _TCP/IP_?

Are you saying that one might ask for built-in UDP support or heavens, raw
IP support? I can hear C getting fatter as we just discuss this.
 
J

Joona I Palaste

Are you saying that one might ask for built-in UDP support or heavens, raw
IP support? I can hear C getting fatter as we just discuss this.

No, I would not be asking "what?" or "what not?" but instead "how?". But
maybe my answer won't make sense after all.
 
L

Lew Pitcher

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Me too, I think because then someone would ask, "Why not DeviceNET" and

I was going to ask "Why not SNA?"
then we'd add that to C and next thing you know, C would only be able to
run on hosted implementations.


Accepted wisdom aside, why /couldn't/ C (in a future incarnation) define
a 'networking' interface in the same flavour as it now provides a file
access interface? The same caveats and exceptions for hosted vs unhosted
that currently apply to the stdio library could be applied to this
hypothetical stdnet library.

To take it a step further, how about abstracting network access into the
implementation of the stdio library? This way, the language wouldn't
have to change to provide networking features. To show what I mean, take
the following example program:

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
FILE *data;

if ((data = fopen("data","w")) != NULL)
fprintf(data,"Hello, World\n");
fclose(data);

return EXIT_SUCCESS;
}

The above program /obviously/ writes to a file called "data". Now, look
at this minor modification:

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
FILE *data;

if ((data = fopen("tcp:127.0.0.1:9","w")) != NULL)
fprintf(data,"Hello, World\n");
fclose(data);

return EXIT_SUCCESS;
}

Does the above program write to the file called "tcp:127.0.0.1:9", or
does it establish a TCP connection with the local discard service and
send it some data? Does it matter, wrt ISO C?






- --

Lew Pitcher, IT Consultant, Enterprise Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFA9DjmagVFX4UWr64RAo83AJ48OYnhgsXXDkllL1ssype0VxMBVwCgqGyU
oZScRtcwsOC0yBB5H/kp8aE=
=5DqQ
-----END PGP SIGNATURE-----
 
A

Arthur J. O'Dwyer

Accepted wisdom aside, why /couldn't/ C (in a future incarnation) define
a 'networking' interface in the same flavour as it now provides a file
access interface? The same caveats and exceptions for hosted vs unhosted
that currently apply to the stdio library could be applied to this
hypothetical stdnet library.

Probably because it wouldn't be useful (which AFAICT was Dan's original
point). If it only does TCP/IP, it's useless to people who want to use
other protocols, and if it only does the kind of "raw" communications
provided by the *nixy accept/bind/connect/listen paradigm, then, well,
people who program on those platforms *already* have that functionality
available, and don't need standard C to provide it.
And raw communications aren't generally useful anyway. What the
client programmer wants is a simple interface, like the "extended
fopen" you describe below. And that interface would have to imply
some kind of really-high-level protocol like, I dunno, HTTP or FTP
or something. Or one of the myriad P2P protocols about which I know
*really* nothing.
In short: Raw communications are too low-level to be an improvement
over OS calls, and high-level communications are too narrowly useful.
Why TCP/IP when what I *really* need is DS/IP (DeathStation Internet
Protocol)? :)
To take it a step further, how about abstracting network access into the
implementation of the stdio library? This way, the language wouldn't
have to change to provide networking features. To show what I mean, take
the following example program:
if ((data = fopen("tcp:127.0.0.1:9","w")) != NULL)

Does the above program write to the file called "tcp:127.0.0.1:9", or
does it establish a TCP connection with the local discard service and
send it some data? Does it matter, wrt ISO C?

Doesn't matter at all. The networking solution is definitely a
perfectly reasonable behavior for a Windows compiler, since Windows
these days blurs the lines between the filesystem and the network
to the point of non-existence (merging Internet Explorer and File
Manager, e.g.). In a compiler explicitly targeted to Windows, I would
definitely expect that fopen("http://www.google.com/", "r") would
behave as if it were reading from a "normal" file full of HTML.
I don't know how much Linux or other OSen blur these lines, though;
I would expect the answer to be "less."

-Arthur
 
E

E. Robert Tisdale

H.A. Sujith said:
Why doesn't the standard library provide (at least basic)
networking facilities using TCP/IP?

Why should it?
What's wrong with the current standards?
Why must C compiler developers implement and distribute
a standard library for networking facilities?
 
E

Eric Sosman

Lew said:
[...]
To take it a step further, how about abstracting network access into the
implementation of the stdio library? This way, the language wouldn't
have to change to provide networking features. To show what I mean, take
the following example program:

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
FILE *data;

if ((data = fopen("data","w")) != NULL)
fprintf(data,"Hello, World\n");
fclose(data);

return EXIT_SUCCESS;
}

The above program /obviously/ writes to a file called "data". Now, look
at this minor modification:

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
FILE *data;

if ((data = fopen("tcp:127.0.0.1:9","w")) != NULL)
fprintf(data,"Hello, World\n");
fclose(data);

return EXIT_SUCCESS;
}

Does the above program write to the file called "tcp:127.0.0.1:9", or
does it establish a TCP connection with the local discard service and
send it some data? Does it matter, wrt ISO C?

Something like the above could be done without any
change at all to Standard C. The implementation, not the
Standard, defines how file name strings are formatted and
what they mean, and nothing's preventing an implementation
from recognizing "tcp:127.0.0.1:9" as the designator for
a socket. (Or for a tuna salad sandwich, for that matter.)

For a concrete example of how different implementations
give different interpretations to identical file name strings,
try this program on several implementations and observe what
happens:

#include <stdio.h>
static void doit(const char *name, const char *text) {
FILE *stream = fopen(name, "w");
if (stream == NULL)
fprintf (stderr, "Can't open %s\n", name);
else {
fprintf (stream, "%s: %s\n", name, text);
fclose (stream);
}
}
int main(void) {
doit ("pro.txt", "Reasons to support euthanasia");
doit ("con.txt", "Reasons to oppose euthanasia");
return 0;
}

Another way to sneak new capabilities into the existing
Standard library interface would be to extend the "mode" string,
with implementation-defined significance for extra characters:

stream = fopen("127.0.0.1:9", "wbTCP");

.... where the Standard defines the "wb" piece and the "TCP"
is a hypothetical implementation-specific add-on -- "undefined"
by the C Standard, but "definable" by cooperating extensions.
 
R

Richard Bos

Lew Pitcher said:
Accepted wisdom aside, why /couldn't/ C (in a future incarnation) define
a 'networking' interface in the same flavour as it now provides a file
access interface? The same caveats and exceptions for hosted vs unhosted
that currently apply to the stdio library could be applied to this
hypothetical stdnet library.

Because networking is even less standardised than file systems. With a
file system at least you know that
- you have files, with names;
- files can be read, and written to;
- files may need to be opened, possibly in varying modes, and closed,
and where these are unnecessary, they're trivial no-ops;
- file operations may fail, but these failures can be detected.

With networks, things are not that simple. Some kinds of networks need
you to authenticate yourself, using name and password, before you can do
anything else. Some kinds don't allow you to authenticate, but may use
your network address to decide whether you're allowed to talk. Some
network services work directly; some use repeated question-and-response;
some set up a continuous connection. And whose abstraction model would
we use? OSI?

Richard
 
D

Daniel Haude

On 14 Jul 2004 07:49:22 -0700,
in Msg. said:
Although most use of networking is done using high-level protocols
a standard network interface would still be useful. For example it would
make easier the development of platform independent libraries for high-level
protocols like HTTP.

Ever heard of POSIX?

--Daniel
 
M

Mark A. Odell

What's your point in asking this question?

That a TCP/IP stack would be difficult to fit in addition to what the
current ISO C compiler supports. Basically, C can be used, as it stands,
on many smaller devices - adding TCP/IP would make C more of a "big
system" language. Unnecessarily I might add.
 
R

Richard Bos

H.A. Sujith said:
The stdio library tries to provide a platform independent I/O library.
Twenty years ago networking may not have been as important or
as standardized as today. But TCP/IP has become the accepted standard

No, it has not. It has become _an_ accepted standard. Not _the_. IPX is
not yet dead, for example.

Richard
 
H

Harti Brandt

On Wed, 14 Jul 2004, Mark A. Odell wrote:

MAO>
MAO>
MAO>>> > Why doesn't the standard library provide (at least basic)
MAO>>> > networking facilities using TCP/IP ?
MAO>>>
MAO>>> What does that mean to an 8-bit microcontroller with 128 bytes of RAM
MAO>>> and 8kB of ROM?
MAO>>
MAO>> What's your point in asking this question?
MAO>
MAO>That a TCP/IP stack would be difficult to fit in addition to what the
MAO>current ISO C compiler supports. Basically, C can be used, as it stands,
MAO>on many smaller devices - adding TCP/IP would make C more of a "big
MAO>system" language. Unnecessarily I might add.

While I don't think that adding TCP/IP support to C makes sense (what
about UDP, TLI vs. sockets, ... and why not just use Posix) your argument
doesn't seem to work. I don't think that really small devices would
support the full hosted environment, do they? An 8-bit microcontroller
with the above characteristics wouldn't support all the standard library.

Also it seems that C is growing more optional parts or are the
standardisation people going to force decimal floating point and address
spaces on every implementation?

harti
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,143
Messages
2,570,822
Members
47,368
Latest member
michaelsmithh

Latest Threads

Top