Programming Forums

Programming Forums (http://www.programmingforums.org/forumindex.php)
-   C++ (http://www.programmingforums.org/forum15.html)
-   -   printing text to a server or something (http://www.programmingforums.org/showthread.php?t=13585)

cwl157 Jul 18th, 2007 6:21 PM

printing text to a server or something
 
I know I've asked about sockets and things like that on here before and people have given me great references but i don't really understand them. Basically i have a program that prints text to the screen. All i want to do is add a couple lines that will not only have that text print to the screen but print to a server of some sort so another person can see the text. So like a chat, one person types something at one end and at the other end another person can read it.
:

cout << "Hello world";
this prints it to the screen. Is there anything like this:
:

myserver >> "Hello world";
and this would print it to a server? I am also familiar with the read and write functions like when reading and writing to a file. Would it be more like those? Or is it something completely different?
Also I am a little confused on how i would have to set it up. Would i have a central server that both people connect to like clients? Or could i just have one person connect to the other and send the text that way?

DaWei Jul 18th, 2007 7:28 PM

Investigate overloading the >> operator for designated streams that you specify. For some streams, you'll have to do nothing but specify the recipient.

grumpy Jul 18th, 2007 7:35 PM

Quote:

Originally Posted by cwl157 (Post 130847)
Is there anything like this:
:

myserver >> "Hello world";
and this would print it to a server?

There is nothing standard like this. You could implement something like this if you wanted to. A class;
:

class CommunicatesWithServer
{
    public:
      // other stuff

        operator<<(const char *);    // send chars to server
};

could be used as;
:

    CommunicatesWithServer  client_stub;  //  a client stub that talks with server
    client_end << "Hello";

The reason for using operator << rather than >> is that you are logically writing data to the server, not extracting to a string, so this would be consistent with the way C++ iostreams work (i.e. no paradigm shift for C++ programmers who understand iostreams).

This relies on their being a server to talk to, obviously.
Quote:

Originally Posted by cwl157 (Post 130847)
I am also familiar with the read and write functions like when reading and writing to a file. Would it be more like those? Or is it something completely different?

You could do that. For client to server comms, a client might send something to the server using some form of write() function and the server might receive it using some form of read() function. For server to client communications, the server could use something like the write() function and the client could use something like the read function.
Quote:

Originally Posted by cwl157 (Post 130847)
Also I am a little confused on how i would have to set it up.

In practice, you need to view the client and server as two things. There is no one function that allows communication between them because you have to establish two ends of the communication link.

Usually, the user of your system would use a client and the server would be remote. The analogy is your web browser (the client) which talks the an internet server.

Essentially, the client needs to establish a connection to the server, and then (in a loop) repetitively wait for both input from the user (which is sent to the server) or for data from the server (which is displayed to the user). A few additional features would be based on interpreting user input (eg when the user wants to quit) and data from the server (eg stop talking to the server if the server refuses connections).

The server needs to do things to complement the client. Usually, it would repetively wait for incoming connections from new clients, receive data from clients, send data back to clients, and cope with client behaviour (eg dropping a connection). This means it can forward data between clients as well.

Quote:

Originally Posted by cwl157 (Post 130847)
Would i have a central server that both people connect to like clients? Or could i just have one person connect to the other and send the text that way?

Those are options. That is an architectural decision that depends on what you're trying to do. There are actually many choices, with different trade-offs.

If your clients have a means of finding each other (eg know each others address) all they need to do is establish connections to each other and communicate. This might be augmented by some "dating server" which allows clients register with so they can find each other, but has no involvement in the actual communications between clients. This (once clients establish links to each other) is essentially "point to point" communications. The trade-off here is that clients do most of the work, and the servers (if any) don't do all that much other than maintain a list of clients. One a linkage is set up, the clients are only vulnerable to behaviour of each other and to the communications medium (eg the cables between them).

Alternatively, the clients may establish links to a server and do all communications with the server. The server then handles forwarding of data between clients. This means all clients only communicates with one server, and the server communicates with many clients. This has an advantage of allowing central administration (eg a moderator who can kick abusive users off a chat line) and the client can share data with multiple users without maintaining individual connections for each online client.

Another alternative is that clients may simply broadcast data into the ether and other clients may simply read data from the ether. No server at all, as such: all that is needed is a communication medium. This means the clients don't necessarily know who is receiving their communications (or if anyone is). It is sort of like shouting from a rooftop and someone happening to be in range who can hear (i.e. is configured to receive from the ether).

Some more sophisticated schemes involve multiple servers. Each client only needs to find one server. The servers communicate with multiple clients and with multiple servers. This allows a network topology. For example, local communications would involve two clients connected to the same server. But remote communications would mean a number of servers acting as intermediaries between clients. This is (more or less) the logic behind telephone exchanges (or mobile phone towers) telephone users being able to communicate with any other telephone user worldwide.

There are many other options; those choice depends on what you're trying to achieve and requirements (eg quality of service, security, need for central administration, .....)

InfoGeek Jul 18th, 2007 10:58 PM

This might help you: http://www.programmingforums.org/for...-problem-.html

pegasus001 Jul 19th, 2007 4:18 PM

What about cgi. I wrote a program(a simple one) in c++, and put it in cgi dir of apache and displayed it on mozilla. Is this what you`re asking for.

cwl157 Jul 19th, 2007 6:12 PM

i'm not sure, basically i want 2 people to send text to each other, which ever is the easiest way to do that. I have done it in unix using named fifos but it seems like windows is completely different. I don't know if the whole server client is nessecary cause its only at most 2 people connected to each other at once and no more. I know with fifos it was one writes to it the other reads from it. Is there something like that in windows?

cwl157 Jul 21st, 2007 3:42 AM

I read the stuff you guys have given me as well as stuff on msdn about sockets and such, and I don't understand it, is really that complicated? There isn't an easy way to send text from one computer to another using some kind of read and write functions like to read and write to a file in C? Maybe i'm in the wrong place. Is it easier in C and not C++ with classes and all that?

grumpy Jul 21st, 2007 10:23 PM

It's not that hard, but you are asking for it to be simpler than it is. The thing to remember is that communication between machines requires actions by both machines. You are assuming it can all be done by the machine that wants to send text, and ignoring the need for the machine that is receiving the text to also do something. To implement one end of the link, you need to implement the other end as well.

It is just as easy in C as in C++. C++ classes are not specifically required (although you may wish to create classes to contain things).

cwl157 Jul 24th, 2007 6:02 PM

alright so basically, i want a server that is going to wait for 2 connections. Then it takes the data sent from one connection and forwards it to the other connection. So it could be like when a computer makes a connection it sends its ip and when the server does the receive command it stores that ip in a variable. Then when it has to send the information to that computer it would know the ip to send it to and use the send function.

then the 2 clients would only be responsable for connecting to the server and sending the info using the send function to the server. And all of this is done with sockets? A function using the socket and the servers ip, i belive it is called connect() connects to the server right? And then uses the send() function to send a character string of information to the server right? and then the server will take that ip address info and call recv() function on that client and get and store the information then it would take the ip address info that was sent by the other computer and use the send() function and send that info out to the other computer, in which the other computer will call recv() and recieve the character string from the server? Does that makes sense?

DaWei Jul 24th, 2007 6:07 PM

At this point I think you want to refer to Beej. It's for Unix sockets, but there isn't a lot of difference with Windows, just see MSDN for Winsock2 stuff.


All times are GMT -5. The time now is 2:41 AM.

Powered by vBulletin® Version 3.7.0, Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Copyright ©2007 DaniWeb® LLC