Programming communication application between 2 sockets

[PsySc0rpi0n]

Hi.

I was trying to learn the basics about sockets programming but I'm stuck with some questions and some code I can't fix.
I have been reading some examples and the one I liked the most was this one:
https://www.binarytides.com/socket-prog ... -tutorial/

However, most examples are meant to create a server that listens and accepts connections and automatically replies to the client. But the client here is a telnet connection to some localhost port.
What I want to do is to code a simple program that I can run 2 instances and then, from 2 different terminal windows, I can send and receive messages between the 2 clients.

So, I started coding but I get to a point where the recv() function returns -1 (some error) and I can't figure out why.
But before showing the code, I want to ask at least two questions that I don't find the answer in any of the examples I've seen.
The usual approach I usually find on these examples is:
1 - create a socket
2 - Bind the socket
3 - Listen for connections
4 - Accept connections
5 - Reply to the client

The first question is not exactly about sockets. It's about binding. I still can't understand what binding means in the different contexts it is used in. Binding applications, binding sockets, etc. I think these two examples have slightly different meanings. Can anyone give me a brief explanation of what binding means?

The second question is about the code. We first create a socket and then, when we are using the accept() function, there is another socket created. Why do we need to create 2 sockets?

Now, on to the code.
https://paste.debian.net/1171406/

I know this is a very dummy code, but the point is that when the code tries to receive messages from the telnet connection, it returns -1, which means some error occurred!
Can anyone tell me what am I doing wrong? I know this is not my goal, but when I get this working, I'll move one to my goal of having 2 instances of this code running and being able to send messages back and forth between the 2 instances.

[reinob]

1. Binding in this context means binding a (listening) socket to a port. Like ssh binds to port 22, etc.
Client connections normally do not explicitly bind to a port, and the kernel just binds them to a random available port.
Servers usually need a fixed/known port, like 22 above.

2. accept() returns a new, connected socket. The listening socket is left untouched.
This is by design. I don't understand your question.

3. you recv() on the connected socket, not on the listening socket, i.e. you need to use

Code: Select all

recv(accSocket, messageIn, BUFFER, 0)


Good luck.
I know it may sound old-fashioned but rather than following a random tutorial, I'd recommend a book such as UNIX Network Programming from W. Richard Stevens.

Otherwise you'll never know e.g. why your passing that "3" parameter to listen().
Of course, the manual is also your friend. man 2 listen, man 2 accept, man 2 recv, etc.

[PsySc0rpi0n]

1. Binding in this context means binding a (listening) socket to a port. Like ssh binds to port 22, etc.
Client connections normally do not explicitly bind to a port, and the kernel just binds them to a random available port.
Servers usually need a fixed/known port, like 22 above.

2. accept() returns a new, connected socket. The listening socket is left untouched.
This is by design. I don't understand your question.

3. you recv() on the connected socket, not on the listening socket, i.e. you need to use

Code: Select all

recv(accSocket, messageIn, BUFFER, 0)


Good luck.
I know it may sound old-fashioned but rather than following a random tutorial, I'd recommend a book such as UNIX Network Programming from W. Richard Stevens.

Otherwise you'll never know e.g. why your passing that "3" parameter to listen().
Of course, the manual is also your friend. man 2 listen, man 2 accept, man 2 recv, etc.

1 - Ok, so binding is like to create a bound between the socket and the port, right? So that the data that comes into that port can be redirected to this socket (file descriptor) which is in turn bound somehow to my program and then my program will know what to do with the data. Is this way of saying things kind of accurate?

2 - I mean, why there is the need of two sockets? Why the first created socket cannot be used to send and receive data?

And btw, it's not old fashioned at all to suggest a reading. I appreciate the suggestion and will take a look at the book.

Now, the next step is try to understand how actually I do what I want. Instead of using telnet to connect to that port, I want to run the same code in a 2nd instance, send and receive messages back and forth.
Do you have any suggestion where to start, from the code I already have.


Edited;
I have also been using these resources too:
http://beej.us/guide/bgnet/
https://www.gnu.org/software/libc/manua ... ml#Sockets

[PsySc0rpi0n]

Well, I changed the code to the following to codes:

Client 1
https://paste.debian.net/1172254/

Client 2
https://paste.debian.net/1172253/


Then, I start client 1 and after, I start client 2, but I get a "Connection refused error.

What do I need to fix?

[reinob]

Well, I changed the code to the following to codes:

Client 1
https://paste.debian.net/1172254/

Client 2
https://paste.debian.net/1172253/


Then, I start client 1 and after, I start client 2, but I get a "Connection refused error.

What do I need to fix?

Your client 2 has

Code: Select all

localSocket.sin_addr.s_addr = INADDR_ANY;


This means it tries to connect to 0.0.0.0, which makes no sense. You use INADDR_ANY when binding a listening port, to listen on all interfaces/addresses.

If you want to connect to 127.0.0.1 (localhost), then you

Code: Select all

localSocket.sin_addr.s_addr = inet_addr("127.0.0.1");


Also, your client 1 is listening on port 25648, but your client 2 attempts to connect to port 25468.
You may want to double-check that :)

[PsySc0rpi0n]

Well, I changed the code to the following to codes:

Client 1
https://paste.debian.net/1172254/

Client 2
https://paste.debian.net/1172253/


Then, I start client 1 and after, I start client 2, but I get a "Connection refused error.

What do I need to fix?

Your client 2 has

Code: Select all

localSocket.sin_addr.s_addr = INADDR_ANY;


This means it tries to connect to 0.0.0.0, which makes no sense. You use INADDR_ANY when binding a listening port, to listen on all interfaces/addresses.

If you want to connect to 127.0.0.1 (localhost), then you

Code: Select all

localSocket.sin_addr.s_addr = inet_addr("127.0.0.1");


Also, your client 1 is listening on port 25648, but your client 2 attempts to connect to port 25468.
You may want to double-check that

Hum, ok.
I didn't know about INADDR_ANNY and about the port, I thought I was using the same port. I didn't notice I swapped 4 and 6 by accident.

Making changes now!
Thank you

[PsySc0rpi0n]

Ok, so, after making the suggested changes I tried to run both clients but still not working.

The thing is that messages that I type on either side, are not going through to the other client. Nothing happens apparently. Then, when I close client1, the 1st message I have typed on client 1 that was supposed to go into client2, is rather executed in the prompt, resulting in a "bash: Hi: command not found".

So, somehow, messages are not going through one client to the other an not coming into recv() functions on either sides.

[reinob]

Both client1 and client2 are, once connected, doing a recv(), which BLOCKS BOTH PROGRAMS until they receive data, which will never happen because both are waiting for data to be received.

You need to first thoroughly think what you actually want to achieve (= your protocol), and then see how you can implement it.

If you really really need to be able to read and write simultaneously on both programs, then you'll need to use poll or other non-blocking receiving mechanisms (like using fcntl to make the socket non-blocking).

I think *now* is the time to read that book, before you get frustrated by all this.
Best of luck!

[PsySc0rpi0n]

Both client1 and client2 are, once connected, doing a recv(), which BLOCKS BOTH PROGRAMS until they receive data, which will never happen because both are waiting for data to be received.

You need to first thoroughly think what you actually want to achieve (= your protocol), and then see how you can implement it.

If you really really need to be able to read and write simultaneously on both programs, then you'll need to use poll or other non-blocking receiving mechanisms (like using fcntl to make the socket non-blocking).

I think *now* is the time to read that book, before you get frustrated by all this.
Best of luck!

Well, it's not that I need to specifically to write and read at the same time on both programs. I can very well, make one to send a message first, and from that point, to be able to get a reply and answer, until an empty message is sent, for instance.
I want to try to not overcomplicate when I only want to lear how sockets work and how a simple sockets program looks like.

[LE_746F6D617A7A69]

I want to try to not overcomplicate when I only want to lear how sockets work and how a simple sockets program looks like.

Mr reinob is right: You need to define the protocol. Sockets are just providing the transport layer, but the actual data synchronization is up to You.
Non-blocking calls to recv() are requiring "manual" collecting of the received data, because of possible fragmentation.
Blocking calls to recv() are more "convenient", but in such case it's impossible to control transmission timeouts - and if We're talking about serious applications, transmission timeouts should be managed/controlled.

[PsySc0rpi0n]

I want to try to not overcomplicate when I only want to lear how sockets work and how a simple sockets program looks like.

Mr reinob is right: You need to define the protocol. Sockets are just providing the transport layer, but the actual data synchronization is up to You.
Non-blocking calls to recv() are requiring "manual" collecting of the received data, because of possible fragmentation.
Blocking calls to recv() are more "convenient", but in such case it's impossible to control transmission timeouts - and if We're talking about serious applications, transmission timeouts should be managed/controlled.

No, we are not talking about serious applications. It's only me getting familiar with socket programming. That's all.
And to be honest, I'm not sure I want to go that deep. I managed to communicate from a telnet session to the server application and I'm kinda happy! So, I'll call it for now! I'm already in a new small project of mine and I'm also facing quite a few problems, because of my lack of experience. It's always the same problem.

Anyways, that you to everyone that helped!

[LE_746F6D617A7A69]

No, we are not talking about serious applications. It's only me getting familiar with socket programming. That's all.

The thing is, that sockets interfaces are quite primitive - the applications which are using the sockets layer are directly responsible for "understanding" the underlying structures. From this point of view, "sockets communication" means that You have to understand the sockets programming very deeply, because otherwise Your code would not work as expected.

Regards.