Why not networking support?

[H.A. Sujith]

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

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark A. Odell wrote:

Joona I Palaste <pa*****@cc.hel sinki.fi> wrote in
news:cd******** **@oravannahka. helsinki.fi:

Why doesn't the standard library provide (at least basic)
networkin g 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.

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

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,"H ello, 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,"H ello, 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)

iD8DBQFA9DjmagV FX4UWr64RAo83AJ 48OYnhgsXXDkllL 1ssype0VxMBVwCg qGyU
oZScRtcwsOC0yBB 5H/kp8aE=
=5DqQ
-----END PGP SIGNATURE-----

[Arthur J. O'Dwyer]

On Tue, 13 Jul 2004, Lew Pitcher wrote:

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: <snip> 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

[Eric Sosman]

Lew Pitcher wrote:

[...]
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,"H ello, 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,"H ello, 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.

--
Er*********@sun .com

[E. Robert Tisdale]

H.A. Sujith wrote:

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?

[Peter Nilsson]

"Mark A. Odell" <od*******@hotm ail.com> wrote in message
news:Xn******** *************** ********@130.13 3.1.4...

"H.A. Sujith" <su****@localho st.localdomain> wrote in
news:slrncf7icc .2sr.su****@loc alhost.localdom ain:

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?

What's your point in asking this question?

--
Peter

[Richard Bos]

Lew Pitcher <Le*********@td .com> wrote:

Mark A. Odell wrote:

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.

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

[H.A. Sujith]

In article <cd**********@n ntp1.jpl.nasa.g ov>, E. Robert Tisdale wrote:

H.A. Sujith wrote:

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?

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 and
networking has become a very important part in computing -- it has
become a part of what we call I/O.

The concept of sockets fits nicely with C's system of streams. It is sad
that we cant use the nice funtions of the stdio library for networking.
(Of course, we can manually do stuff like changing file descriptors but
things like that are prone to errors.) A consistent nertworking interface
would not only make applications more portable, it would also make more
applications portable.

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.

--
mail to: randomzoo <at> spymac <dot> com

[Daniel Haude]

On 14 Jul 2004 07:49:22 -0700,
H.A. Sujith <su****@localho st.localdomain> wrote
in Msg. <slrncfa831.16p .su****@localho st.localdomain>

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

--
"With me is nothing wrong! And with you?" (from r.a.m.p)

[Mark A. Odell]

"Peter Nilsson" <ai***@acay.com .au> wrote in
news:40******@n ews.rivernet.co m.au:

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

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.

--
- Mark ->
--

[Richard Bos]

"H.A. Sujith" <su****@localho st.localdomain> wrote:

In article <cd**********@n ntp1.jpl.nasa.g ov>, E. Robert Tisdale wrote:

H.A. Sujith wrote:

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

Why should it?

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