Networking in C++?

A place to discuss the implementation and style of computer programs.

Moderators: phlip, Moderators General, Prelates

HappySmileMan
Posts: 52
Joined: Fri Nov 09, 2007 11:46 pm UTC

Networking in C++?

Postby HappySmileMan » Wed Dec 26, 2007 9:40 pm UTC

I've been using C++ for a good while now, and I've always wanted to know why you can use streams for input/output to the console, and streams for input/output to files but there's no built-in way (AFAIK) to use streams for network I/O.

Is there any good reason for this?

arcoain
Posts: 56
Joined: Thu Dec 20, 2007 12:34 am UTC

Re: Networking in C++?

Postby arcoain » Wed Dec 26, 2007 9:50 pm UTC

It depends. If you are using Visual c++.Net, there is the System.Net.Sockets.Socket class to handle that sort of thing. Its nearly-impossible/extremely difficult to do in native c++. I'm sure someones written a library though...
arcoain

User avatar
hotaru
Posts: 1041
Joined: Fri Apr 13, 2007 6:54 pm UTC

Re: Networking in C++?

Postby hotaru » Wed Dec 26, 2007 9:58 pm UTC

Code: Select all

factorial product enumFromTo 1
isPrime n 
factorial (1) `mod== 1

HappySmileMan
Posts: 52
Joined: Fri Nov 09, 2007 11:46 pm UTC

Re: Networking in C++?

Postby HappySmileMan » Wed Dec 26, 2007 10:10 pm UTC



Might have to look into this, though I would probably just go with QNetwork (part of QT), I'm not too worried about finding out how to do it, I'm really just wondering why they didn't make streaming with networks as easy as with files and console stuff in standard C++, since I can't really see a reason against it.

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Networking in C++?

Postby EvanED » Thu Dec 27, 2007 12:29 am UTC

HappySmileMan wrote:I'm not too worried about finding out how to do it, I'm really just wondering why they didn't make streaming with networks as easy as with files and console stuff in standard C++, since I can't really see a reason against it.

Standard C++ doesn't have any network support currently, which is in some ways a very good reason why it's not as easy and in some ways not a reason at all. ;-)

User avatar
yy2bggggs
Posts: 1261
Joined: Tue Oct 17, 2006 6:42 am UTC

Re: Networking in C++?

Postby yy2bggggs » Thu Dec 27, 2007 3:44 am UTC

HappySmileMan wrote:Is there any good reason for this?

Yes.
Bjarne Stroustrup wrote:C++ is a language, not a complete system
(from Design and Evolution of C++)

Typically, TCP/IP is provided as a part of your operating system environment. C++'s design goals are simply to adapt to the system you are in. That's not to say that there aren't or shouldn't be any C++ libraries for network I/O, but rather, the language itself isn't going to define them. The need to define basic I/O is a bit different in this regard because it's a more fundamental middle language need.

That C++ is not intended to be a complete system is also a reason why there's no built in library for a number of other things.
Image

kmatzen
Posts: 214
Joined: Thu Nov 15, 2007 2:55 pm UTC
Location: Ithaca, NY

Re: Networking in C++?

Postby kmatzen » Thu Dec 27, 2007 10:16 pm UTC

I second QtNetwork. I know how to use QSocket and QServerSocket. Pretty simple really. And Qt 4.4.0 technical preview just came out so you might want to take a look at that as well since it adds some nice web browsing features. Btw, Qt is portable to Linux, Mac, and Windows, and Qtopia provides a way to create GUI's for embedded linux devices.

Workaphobia
Posts: 121
Joined: Thu Jan 25, 2007 12:21 am UTC

Re: Networking in C++?

Postby Workaphobia » Fri Dec 28, 2007 12:45 am UTC

yy2bggggs wrote:That C++ is not intended to be a complete system is also a reason why there's no built in library for a number of other things.

I thought Bjarne said he'd like to see a GUI system built into the standard library. If he'd consider something that complicated, you'd think this wouldn't be a big step. If we're worried about differences between operating systems, shouldn't we not even have a file IO library?

Meh, I kind of managed to convince myself of the opposite even as I typed that, but still, it'd be nice to have a larger standard library.
Evidently, the key to understanding recursion is to begin by understanding recursion.

The rest is easy.

User avatar
yy2bggggs
Posts: 1261
Joined: Tue Oct 17, 2006 6:42 am UTC

Re: Networking in C++?

Postby yy2bggggs » Fri Dec 28, 2007 1:45 am UTC

Workaphobia wrote:I thought Bjarne said he'd like to see a GUI system built into the standard library. If he'd consider something that complicated, you'd think this wouldn't be a big step.

Perhaps not... I'm sure it was considered as well.
If we're worried about differences between operating systems, shouldn't we not even have a file IO library?

But one of the main reasons for rejection is that C++ just plops right into your OS anyway, and it doesn't try to be a complete system. As such, the language gets a GUI library anyway when you're on, say, Windows.

The problem with defining a standard GUI library is much more difficult; a standard GUI C++ library needs to be all things to all people. This design guideline means that C++ doesn't have to define a complete system, just being able to adapt to your own is enough.

I agree this is more complex than networking, but the same thing applies there. But basic I/O is a much more basic thing to tackle (consider that I/O is introduced early on in any language 101 class).
Image

User avatar
Sc4Freak
Posts: 673
Joined: Thu Jul 12, 2007 4:50 am UTC
Location: Redmond, Washington

Re: Networking in C++?

Postby Sc4Freak » Fri Dec 28, 2007 2:10 am UTC

Workaphobia wrote:
yy2bggggs wrote:That C++ is not intended to be a complete system is also a reason why there's no built in library for a number of other things.

I thought Bjarne said he'd like to see a GUI system built into the standard library. If he'd consider something that complicated, you'd think this wouldn't be a big step. If we're worried about differences between operating systems, shouldn't we not even have a file IO library?

Meh, I kind of managed to convince myself of the opposite even as I typed that, but still, it'd be nice to have a larger standard library.

I'd be very surprised if Stroustup actually said that. C++ doesn't even require that the system have a keyboard, or a monitor, or a file system. The basic IO libraries are there because, well, they're one of the most basic components of a computer.

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Networking in C++?

Postby EvanED » Fri Dec 28, 2007 4:50 am UTC

Sc4Freak wrote:The basic IO libraries are there because, well, they're one of the most basic components of a computer.

Really? I'm not sure I agree with this. Think of all the headless embedded apps that would want a network lib but no I/O and no local writable storage. I don't know if this would have been true in the mid 90s, but I think a networking component would be just as fundamental now as standard and file I/O.

User avatar
Sc4Freak
Posts: 673
Joined: Thu Jul 12, 2007 4:50 am UTC
Location: Redmond, Washington

Re: Networking in C++?

Postby Sc4Freak » Fri Dec 28, 2007 7:26 am UTC

EvanED wrote:
Sc4Freak wrote:The basic IO libraries are there because, well, they're one of the most basic components of a computer.

Really? I'm not sure I agree with this. Think of all the headless embedded apps that would want a network lib but no I/O and no local writable storage. I don't know if this would have been true in the mid 90s, but I think a networking component would be just as fundamental now as standard and file I/O.

Hmm, good point. I hadn't thought about embedded systems.

User avatar
laranzu
Posts: 104
Joined: Fri Nov 30, 2007 4:21 pm UTC
Location: Physical: Canberra, Australia
Contact:

Re: Networking in C++?

Postby laranzu » Fri Dec 28, 2007 11:35 am UTC

C++ most likely doesn't include built-in network IO streams because the idea that socket == stream is only true for Unix. It isn't true for MS Windows, and wasn't for MacOS and a number of other operating systems when C++ was being developed in the 1990s.

Even on Unix, socket == stream is only true for TCP. It doesn't make a lot of sense for UDP (how do you batch values into packets? what do you do on lost input?) and multicast or SCTP is even less like a console or file.

If you do want a quick way to use C++ streams for network IO, nc (netcat) is your friend on Linux or MacOS X. Write standard C++ << and >> to stdin/stdout and pipe it into nc on the command line.

User avatar
segmentation fault
Posts: 1770
Joined: Wed Dec 05, 2007 4:10 pm UTC
Location: Nu Jersey
Contact:

Re: Networking in C++?

Postby segmentation fault » Fri Dec 28, 2007 5:25 pm UTC

the idea is to build your classes using c sockets.
people are like LDL cholesterol for the internet

User avatar
yy2bggggs
Posts: 1261
Joined: Tue Oct 17, 2006 6:42 am UTC

Re: Networking in C++?

Postby yy2bggggs » Fri Dec 28, 2007 7:34 pm UTC

laranzu wrote:C++ most likely doesn't include built-in network IO streams because the idea that socket == stream is only true for Unix.

Not true. TCP implements a stream. But yeah, not everything in networking even is a stream; still, I think the idea people have here is to create some sort of streamable library designed to go over nets.

But for this particular need, iostreams just hooking into a domain specific API doesn't seem that bad (and lets you control all of the strange particulars such as OOB data, blocking, domain level reconnect protocols, etc).

For networking needs in general, you need something more than just streams anyway. From an abstract perspective, a choice between stream and packeting, where the packeting interface can be guaranteed state delivery, guaranteed in order delivery, and non-guaranteed delivery would be nice (off the top of my head).

Still, I wouldn't necessarily want my language to standardize IPv4 if my code is going to outlast the protocol (and my language can use the environment's support for the same).
Image

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Networking in C++?

Postby EvanED » Sat Dec 29, 2007 3:01 pm UTC

laranzu wrote:C++ most likely doesn't include built-in network IO streams because the idea that socket == stream is only true for Unix. It isn't true for MS Windows...

Methinks you need to look at the Windows sockets interface again... it is very close to Berkeley sockets.

If you do want a quick way to use C++ streams for network IO, nc (netcat) is your friend on Linux or MacOS X. Write standard C++ << and >> to stdin/stdout and pipe it into nc on the command line.

Which only works if you don't want other I/O.

User avatar
laranzu
Posts: 104
Joined: Fri Nov 30, 2007 4:21 pm UTC
Location: Physical: Canberra, Australia
Contact:

Re: Networking in C++?

Postby laranzu » Sun Dec 30, 2007 1:46 am UTC

EvanED wrote:
laranzu wrote:C++ most likely doesn't include built-in network IO streams because the idea that socket == stream is only true for Unix. It isn't true for MS Windows...

Methinks you need to look at the Windows sockets interface again... it is very close to Berkeley sockets.


Poor wording by me. I should have writen "socket == file" for Unix.

MS Windows sockets are very close to the Berkeley sockets, but they aren't interchangeable with regular file descriptors as they are in Unix. (At least up to and including Windows 2000 AFAIK.) A Linux/MacOS X process could rebind stdin and stdout to sockets then fork a child, and the child could use C++ << and >> for IO without noticing that the data was actually going over the network.

If most other operating systems had the same capability, I'm sure the C++ designers would have offered network sockets as standard C++ iostreams.

It is odd though that you can rebind stdin and stdout in C code, but I haven't seen any easy way to redirect the stdin/stdout streams in C++.

User avatar
yy2bggggs
Posts: 1261
Joined: Tue Oct 17, 2006 6:42 am UTC

Re: Networking in C++?

Postby yy2bggggs » Sun Dec 30, 2007 2:24 pm UTC

laranzu:

The only thing you've described that the windows API doesn't support is fork.
laranzu wrote:It is odd though that you can rebind stdin and stdout in C code, but I haven't seen any easy way to redirect the stdin/stdout streams in C++.

How would you do such a thing using the standard C library?
Image

User avatar
laranzu
Posts: 104
Joined: Fri Nov 30, 2007 4:21 pm UTC
Location: Physical: Canberra, Australia
Contact:

Re: Networking in C++?

Postby laranzu » Sun Dec 30, 2007 5:40 pm UTC

yy2bggggs wrote:laranzu:

The only thing you've described that the windows API doesn't support is fork.


Which is the essential one :-( With fork() on Unix the parent process can reassign stdin and stdout for a child process (plus stderr for that matter) and the child doesn't have to know about it. MS Windows doesn't (AFAIK up to and including Windows 2000) have this capability.

yy2bggggs wrote:
laranzu wrote:It is odd though that you can rebind stdin and stdout in C code, but I haven't seen any easy way to redirect the stdin/stdout streams in C++.

How would you do such a thing using the standard C library?


My C programming books are at work, but on Unix with integer file descriptors you could redirect stdout to a TCP socket with something like:

connect(sock, &my_sockaddr, sizeof(my_sockaddr));
close(1);
dup2(sock, 1);

Using just <stdio.h> I don't believe you can redirect stdin or stdout to a network socket, but you can redirect them to a file with something like:

freopen("some_file_name", "w", stdout);

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Networking in C++?

Postby EvanED » Sun Dec 30, 2007 6:23 pm UTC

laranzu wrote:
yy2bggggs wrote:laranzu:

The only thing you've described that the windows API doesn't support is fork.


Which is the essential one :-( With fork() on Unix the parent process can reassign stdin and stdout for a child process (plus stderr for that matter) and the child doesn't have to know about it. MS Windows doesn't (AFAIK up to and including Windows 2000) have this capability.

Windows has had this ability for pipes and files since... well, for ages. Well before Win2K. It sounds like you may be right about sockets though.

Agreed that the Windows process creation routine is notably inferior to Unix though. The CreateProcess API is too complex for what it does; fork-then-exec is much cleaner in almost all cases.

freopen("some_file_name", "w", stdout);

I also don't have books handy, but there is a way to do something at least similar (minus sockets) in C++ with iostreams. The stream objects have backing "streambuf" objects, and you can reassign them, so you can do something like

Code: Select all

fstream redir("output.txt");
cout.rdbuf(redir.rdbuf());

User avatar
yy2bggggs
Posts: 1261
Joined: Tue Oct 17, 2006 6:42 am UTC

Re: Networking in C++?

Postby yy2bggggs » Sun Dec 30, 2007 6:29 pm UTC

laranzu wrote:Which is the essential one :-(
Nonsense. You can't use CreateProcess or CreateThread? In this case, sense you're not using exec to replace the process, what's wrong with the CreateThread approach?
My C programming books are at work, but on Unix
The question was about the standard C library, not UNIX libraries. After all, this thread asks why something isn't in the C++ standard library, not why it's not available to C++.

But in regards to MS Windows, here's what I'd do (shown outside of code tags to support links to MSDN documentation):
connect(sock, &my_sockaddr, sizeof(my_sockaddr));
_close(1);
_dup2(sock, 1);
(the forms without underscores are deprecated).

Using just <stdio.h> I don't believe you can redirect stdin or stdout to a network socket, but you can redirect them to a file with something like:

freopen("some_file_name", "w", stdout);

That doesn't exactly redirect--it reopens stdout. C++, by the way, incorporates C libraries. What you have in C <stdio.h> can be found in <cstdio> (using preferred libraries). Please understand this vital point--every standard C(89) facility is available to C++.

But you can redirect C++'s cout, using rdbuf(). Not only that, but you can write your own basic_streambuf that handles TCP/IP and redirect to that, fairly easily.

Edit:
EvanED wrote:The CreateProcess API is too complex for what it does; fork-then-exec is much cleaner in almost all cases.

(sigh)...
_exec
Image

EvanED
Posts: 4331
Joined: Mon Aug 07, 2006 6:28 am UTC
Location: Madison, WI
Contact:

Re: Networking in C++?

Postby EvanED » Sun Dec 30, 2007 7:28 pm UTC

[Sorry for keeping up this off topic conversation]
yy2bggggs wrote:
laranzu wrote:Which is the essential one :-(
Nonsense. You can't use CreateProcess or CreateThread? In this case, sense you're not using exec to replace the process, what's wrong with the CreateThread approach?

Sure you are. Suppose you want to run another program with its standard output redirected somewhere. For instance, you are writing a shell, and want to interpret "program.exe > output.txt". Under Unix, you fork, in the parent execute wait, and in the child close stdout, open output.txt (which will get the stdout file descriptor), then exec. In Windows, you open output.txt, store the file descriptor in a structure, and pass that to CreateProcess. (Then, if you're me, you ignore the part of the docs that say that you have to also pass STARTF_USESTDHANDLES as a flag to CreateProcess and wonder why it's not working.)

From this description the difference isn't apparent, but the problem is that Unix's fork/exec remain simple, but Windows has to add parameters to CreateProcess for anything you'd want to do. In Unix, if you want to run the child in a different security context, you fork, setuid, and exec. In Windows, the context is a parameter to CreateProcess. If Unix, if you want to run the child process from a different working directory, you fork, chdir, then exec. In Windows, it's another parameter to CreateProcess.

CreateProcess kills a lot of orthogonality that is in the Unix API. This is why fork takes no parameters and exec essentially 3 (depending on the exact form and how you count) while CreateProcess takes 10, including a pointer to a structure with 15 fields. Granted, a lot of this is not apropos to Unix -- for instance, the starting location and size of the child process's window -- and doesn't fit well into the fork-change-exec model, but a lot of this complexity could have been reduced.

Edit:
EvanED wrote:The CreateProcess API is too complex for what it does; fork-then-exec is much cleaner in almost all cases.

(sigh)...
_exec

I notice there's no _fork though.

User avatar
yy2bggggs
Posts: 1261
Joined: Tue Oct 17, 2006 6:42 am UTC

Re: Networking in C++?

Postby yy2bggggs » Sun Dec 30, 2007 9:30 pm UTC

EvanED wrote:[Sorry for keeping up this off topic conversation]
You aren't reading carefully enough. There is relevance here to the topic until such a point that you discuss the alleged yet abstract and ephereal superiority of fork versus CreateProcess (why not add taskSpawn as well?) The relevance here is related to support by prototypical popular OS's of various types of features and capabilities, in relation to whether or not support for such features should be added to the standard language library for C++.

In particular, it is a fact that both UNIX and Windows support not only integer based sockets, but TCP/IP implementations based on these sockets. But there's no TCP/IP to be found in the standard C++ library (or the standard C library; apparently, part of the confusion others are having is confusing ability to call something using a language with its being in the language's standard library).
I notice there's no _fork though.

Doesn't matter if you realize why this is on topic. The very capabilities that laranzu said were not in windows, are. This is a factual claim. To say they aren't there is quite plainly incorrect.
yy2bggggs wrote:
laranzu wrote:Which is the essential one :-(
Nonsense. You can't use CreateProcess or CreateThread? In this case, sense you're not using exec to replace the process, what's wrong with the CreateThread approach?

Sure you are. Suppose you want to

Irrelevant response. You're generalizing to a cherry picked case. When laranzu said fork is essential, that should be read that without fork, you can't have this capability.

Well, Windows has no native fork, and you can implement the capabilities--without even writing entire libraries. Furthermore, his example neither required fork/exec nor used it. To support something like fork, OTOH, would be much more complex in Windows, but we're not discussing fork, are we?

Your entire discussion about how orthogonal fork is related to CreateProcess is irrelevant. fork/setuid/etc aren't in Windows for a reason--they do not fit well into the Windows model. That means the OS's are different, which is all the more reason C++ shouldn't standardize this--unless you're going to make the argument that C++ should standardize POSIX as part of its language. Is this your argument?

Still, the Windows product lines evolving from NT based systems are largely POSIX based, and can in fact do what laranzu said it can't. That's a factual claim, and that's the only sort of claim that's relevant here. That it's more complicated to use CreateProcess yada yada is irrelevant--those are political criticisms against an API trying to solve a different issue anyway, and discussions about how much hair you pull out when you do Windows belongs in that other forum so I can ignore it.

The point of linking to MSDN documentation for these things is to demonstrate just how deep socket support actually does run into windows, which is pretty deep. I cannot fathom what the relevance of Windows not having an exact equivalent to fork is in relation to this.

Edit: The point of linking to exec is to show its relation to this same issue. It's not only something called exec that spawns a process--it's the same exec! (e.g., keeps existing handles open).

Edit: Just to emphasize the major point here--Windows and *nix OS's are "just different" in many ways. Arguments against one OS's superiority are ephemeral, religious in nature instead of fact based. Standardizations of features in C++ are not based on religious criteria--though they often involve politics, it's more of a political hurdle/compromise that gets something standard accepted than it is political muscling/worship of The Correct Way. In other words, a feature has to generally be all things to all people. And that is a Good Thing.
Image

User avatar
laranzu
Posts: 104
Joined: Fri Nov 30, 2007 4:21 pm UTC
Location: Physical: Canberra, Australia
Contact:

Re: Networking in C++?

Postby laranzu » Mon Dec 31, 2007 1:53 am UTC

yy2bggggs wrote:Doesn't matter if you realize why this is on topic. The very capabilities that laranzu said were not in windows, are. This is a factual claim. To say they aren't there is quite plainly incorrect.
yy2bggggs wrote:
laranzu wrote:Which is the essential one :-(
Nonsense. You can't use CreateProcess or CreateThread? In this case, sense you're not using exec to replace the process, what's wrong with the CreateThread approach?

Sure you are. Suppose you want to

Irrelevant response. You're generalizing to a cherry picked case. When laranzu said fork is essential, that should be read that without fork, you can't have this capability.


Please note that I was talking about fork() as being essential for the parent process to redirect stdin or stdout to a network socket within a child process, following up my earlier post about that being one way for a C++ program to use << and >> on iostreams over the network. Yes I was cherry picking, because that was the original topic of discussion.

Also note that I've been careful all along to say "AFAIK up to and including Windows 2000" which is the last time I did any serious MS Windows development.

AFAIK, Unix can transparently redirect stdin and stdout of a child process to network sockets, which is a capability MS Windows doesn't have. I'm happy to be proved wrong on this. If you have some MS Windows code that can pass network sockets in place of file handles to CreateProcess, I'd be most interested in seeing it.

yy2bggggs wrote:Edit: Just to emphasize the major point here--Windows and *nix OS's are "just different" in many ways. Arguments against one OS's superiority are ephemeral, religious in nature instead of fact based. Standardizations of features in C++ are not based on religious criteria--though they often involve politics, it's more of a political hurdle/compromise that gets something standard accepted than it is political muscling/worship of The Correct Way. In other words, a feature has to generally be all things to all people. And that is a Good Thing.


I think we are in violent agreement on this.

User avatar
Sc4Freak
Posts: 673
Joined: Thu Jul 12, 2007 4:50 am UTC
Location: Redmond, Washington

Re: Networking in C++?

Postby Sc4Freak » Mon Dec 31, 2007 8:53 am UTC

laranzu wrote:
yy2bggggs wrote:Doesn't matter if you realize why this is on topic. The very capabilities that laranzu said were not in windows, are. This is a factual claim. To say they aren't there is quite plainly incorrect.
yy2bggggs wrote:
laranzu wrote:Which is the essential one :-(
Nonsense. You can't use CreateProcess or CreateThread? In this case, sense you're not using exec to replace the process, what's wrong with the CreateThread approach?

Sure you are. Suppose you want to

Irrelevant response. You're generalizing to a cherry picked case. When laranzu said fork is essential, that should be read that without fork, you can't have this capability.


Please note that I was talking about fork() as being essential for the parent process to redirect stdin or stdout to a network socket within a child process, following up my earlier post about that being one way for a C++ program to use << and >> on iostreams over the network. Yes I was cherry picking, because that was the original topic of discussion.

Also note that I've been careful all along to say "AFAIK up to and including Windows 2000" which is the last time I did any serious MS Windows development.

AFAIK, Unix can transparently redirect stdin and stdout of a child process to network sockets, which is a capability MS Windows doesn't have. I'm happy to be proved wrong on this. If you have some MS Windows code that can pass network sockets in place of file handles to CreateProcess, I'd be most interested in seeing it.

In Windows, you can certainly redirect a child process's stdin/stdout to a parent process transparently (not requiring code modification to the child). I have little experience regarding networking, but I'm sure that it would be possible to take the redirected stdout and pipe it through a network.


Return to “Coding”

Who is online

Users browsing this forum: No registered users and 13 guests