C++ Network Programming

[MIZ]

I want to get into C++ network programming.
What libraries need to be use ?
What is network programming for ?
What can I do with it ?
How many types are there and what's a protocol I hear that word so often ?

Can I have easy to understand ideas because I don't know what network programming is but it sounds worth the study.
Also good resources will help.

Thank you for any relies

[Little Bobby Tables]

What libraries need to be use ?

any socket lib. you can do something os-specific and use winsock/posix sockets/BSD sockets. there is also sfml, sdl, and qt sockets. Personally I prefer an Aysnc solution and use boost.asio

What is network programming for ?

sending data from a client program to a server program

What can I do with it ?

send data from a client program and recieve it from a starter program.

How many types are there and what's a protocol I hear that word so often ?

types of what?
a protocol for network engineers is like a programming language for programmers. a protocol is a set of (usually) standardized rules for sending and recieving data from point A to point B. Some common ones are HTTP, IRC, and SSH, all of which are usually implemented as a daemon (ie httpd, ircd, sshd)

[MIZ]

Thanks for the reply
So i have to get a socket library to do network programming ?
Also is socket programming and network programming the same thing ?

Also does SFML have a socket library as well so i can start network programming from SFML.

So its basically sending data between two different computers ?

Sorry im only 13 years old im really interested in programming and so far im doing good at it.

[MIZ]

Almost forget once i pick a socket library i can programme in any protocol of my choice ?
Which are the most common protocols.

[LB]

SFML, Boost, and Lacewing all have networking support.

There is no "most common protocol" - most applications write one from scratch. Then again, I guess you could consider HTTP a protocol, in which case it is the most common despite being not very useful for games.

[MIZ]

So with all these protocols i can use them to make lets say a messenger to send messages to other users and allow them to write back ?

[IWishIKnew]

Check out boost's ASIO library. That should be everything you need right there.

[ultifinitus]

Honestly I found OS sockets far easier to work with than many other libraries- unix style posix sockets are especially easy to work with. Windows stuff is not terribly difficult either if you keep your nose in the documentation.

[MIZ]

I hear win sockets are a pain

Also I don't run on unix I mite give it ago in the future when I buy another pc

[IWishIKnew]

In my experience, attempting to learn the Windows API was a hellish nightmare... When I switched to Linux, it was like the heavens opened up to me, and I heard a chorus of angels singing as the light shined through the clouds and the fog was lifted.

(slight exageration)

[ultifinitus]

Meh, once you get your sockets connected you can make your communication quite simple

int bsend(int socket, const std::vector<char>& sends, char startchar, char endchar){
    std::stringstream ss("");
    ss << startchar;
    ss << sends.size();
    ss << endchar;

    if (send(socket,ss.str().c_str(),ss.str().size(),0) < ss.str().size())
        return -1;

    if (send(socket,&sends[0],sends.size(),0) < sends.size())
        return -1;

    return sends.size();
}

[Little Bobby Tables]

Then again, I guess you could consider HTTP a protocol, in which case it is the most common despite being not very useful for games.

it *is* a protocol :p

Honestly I found OS sockets far easier to work with than many other libraries- unix style posix sockets are especially easy to work with. Windows stuff is not terribly difficult either if you keep your nose in the documentation.

i really think thats just you. ive never had a good experience with POSIX sockets and they look extremely ugly.

[S G H]

Never work with raw sockets.
Pick somebody else's library such as SFML and stick with it.
You'll thank me.

If you use TCP (and you should unless you're making a game) think of two pipes connecting two pc's.
One pipe sends data from PC A to PC B, the other pipe does the opposite.
What one pc sends the other pc receives, byte by byte, in the same order.
To allow your application to be portable, you should have a serialization layer, or you should send your data as text.
@LB: The P in HTTP actually means Protocol.

[Little Bobby Tables]

If you use TCP (and you should unless you're making a game)

i can think of a few more reasons ;)

[ultifinitus]

S G H wrote:

Never work with raw sockets.
Pick somebody else's library such as SFML and stick with it.
You'll thank me.

Though you may be correct, I recommend perhaps abstaining from the phrase "never" when dealing with development. When a respected person says something using strong words it's often taken for doctrine. As a community programmers should be about possibility and freedom, right?

[LB]

I know HTTP is a protocol, but in the context of games it is not very useful so I exclude talking about it in most cases.

[Avilius]

MIZ wrote:

I hear win sockets are a pain

They're literally almost identical to the Unices, so I don't think the source where you got that from is very reliable...

The only differences are the initialization and shutdown of the API, which is quite trivial.

IWishIKnew wrote:

In my experience, attempting to learn the Windows API was a hellish nightmare... When I switched to Linux, it was like the heavens opened up to me, and I heard a chorus of angels singing as the light shined through the clouds and the fog was lifted.

While it's definitely not the best API, it's quite sane aside from the naming conventions.

It does have a bit (actually quite a bit) of baggage from it's older days, but no more than *nix APIs do.

S G H wrote:

Never work with raw sockets.
Pick somebody else's library such as SFML and stick with it.
You'll thank me.

SFML's networking API is really just a very light abstraction over BSD sockets, so I don't see how using raw sockets is anymore painful than that.

Of course I do understand that everyone doesn't really like working lower level like I do, but if you're going to use a networking library at least use something more high-level such as RakNet or ENet. SFML's networking API isn't much of an upgrade.

[Little Bobby Tables]

They're literally almost identical to the Unices

they literally arent, actually, otherwise windows would completely drop the winapi and pick up posix

The only differences are the initialization and shutdown of the API, which is quite trivial.

among a million other things.

, so I don't think the source where you got that from is very reliable...

funny... i was about to say the same to you...

It does have a bit (actually quite a bit) of baggage from it's older days, but no more than *nix APIs do.

actually, it has a lot more baggage than POSIX sockets. this is due to the fact that posix sockets and winsock were created for different reasons

SFML's networking API is really just a very light abstraction over BSD sockets,

there are more than one kind of raw sockets. have you used sys/inet.h? those are posix sockets (iirc. its some sort of standard). that *is* a light layer over BSD sockets. SFML providesa a great deal more of an abstraction.

[MIZ]

So which socket should I use for games
And which socket should I use for applications that I would like to make

One more question are socket libraries made with raw sockets like winsocket

[S G H]

Socket libraries use the sockets the target system provides.
@Avilius: Making an asynchronous socket's been a nightmare my first time.
Also my SFML suggestion isn't for highlevel networking, but for portable lowlevel-ish networking.
This allows him to understand how protocols work while being sure the networking code is correct for every system.
@MIZ: TCP is a reliable socketing protocol.
Every message sent WILL be received by the target PC in the order it was sent, 1:1 copy.
UDP is an unreliable socketing protocol.
Every message sent *may* be received by the target PC in no specific order. Packets may get lost and their size must be reasonable (too big of a message and it's a big trouble).
I suggest you to use something like RakNet for UDP since UDP is a very complex system.

Now now you may think, why use UDP at all?
Well, UDP is a lot faster. Reliability and sequencing informations are checked on the application's side, if needed.
TCP is very slow. Reliability and sequencing is a builtin feature. It is always checked, even if you don't need it.