Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 2 years ago.
Improve this question
hi i'm following this simple tutorial (from https://www.geeksforgeeks.org/udp-server-client-implementation-c/ ) to create a udp client and server . But i got some issue indeed i always have this error : bind failed: Address already in use
I have already changed the port and granted permission but the error is still there.
Why does this error occur?
After your socket call and before your bind call, you need to set up the socket to reuse the address (e.g.):
// Configure server socket
int enable = 1;
// This allows you to avoid: 'Bind: Address Already in Use' error
int ret = setsockopt(server_sockd, SOL_SOCKET, SO_REUSEADDR,
&enable, sizeof(enable));
See man 7 socket for details.
Related
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 3 years ago.
Improve this question
The following code is simplified.I have a server with a loop:
while(1){
fd_c = accept(fd_skt, NULL, 0);
reading = read(fd_c, buffer, 1024);
writen(fd_c, send_ok, msg_length);
}
and a client with a library which contains a socket and two functions:
int fd_skt = -1;
int connection(){
fd_skt = socket(AF_UNIX, SOCK_STREAM, 0)
connect(fd_skt, (struct sockaddr *) &skt_address, sizeof(skt_address))
writen("hello");
readn();
}
int send_another_message(){
if(fd_skt < 0)
return error(ERR_SKT_NOT_READY);
writen("I am Bob");
readn();
}
If I do this in my client the server will receives two "hello":
connection();
connection();
but if i do this in my client the server will only receive "hello" and not "I am Bob":
connection();
send_another_message();
the server doesn't receive messages.
When I use send_another_message, I don't establish a new connection (because it was previously connected with previous function call).
I can post the entire code if need.
Your server reads and writes only once on the connection, then the next loop iteration calls accept again, which will either block until there is a new connection or return an error value. In either case you overwrite your file descriptor fd_c. Therefore the server is no longer able to communicate with the old connection.
Accept the connection once, and keep the file descriptor around until the connection is closed, so you can reuse it for calls to read and write.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 4 years ago.
Improve this question
I am wondering if you need to set up the server and client sockets so that they always go
send recv send recv ...
Because I am getting an issue where I send a message, and then the initial send() receives it twice.
I send the message upload foo.c
Server displays: Message received: upload foo.c
But then the server prints the actual file contents, which should have been passed to another recv() socket call (since only the first socket in the while loop has it's contents printed)
Message received: This is some text from
the file foo.c
text hello ending
So I get the feeling it's "overflowing" into the next recv iteration.
I'm guessing you use TCP? Then you have to remember that TCP is a streaming protocol, without message boundaries and without any start or end (except connection established and closed).
A single recv call may receive less or more than what was sent in a single send call.
You need to come up with a higher-level protocol which incorporates message boundaries explicitly, for example by sending the length of the data to be received. Then you have to use loops to receive the correct amount of bytes.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 6 years ago.
Improve this question
I'm running into a strange issue trying to test a simple socket program. When I call the "accept" function here, my program seems to hang... it prints out "SENPAI PLS" but never "SADDASSDA".
I was getting past this part of my code last night. For context, this is running on a large server with quite a few other students probably trying to do the same project as me, and I'm sure some of them are leaving their server programs running.
Could the service being busy or full cause accept to just never finish?
do{
printf("SENPAI PLS\n");
clientFD=accept(serverFD, (struct sockaddr *) &clientAddress, &clientAddressSize);
printf("SADDASSDA\n");
if(clientFD==-1){
sleep(1);
}
}while (clientFD==-1);
accept will not return until a connection is accepted (unless the listening socket is in nonblocking mode).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)
Am I correct in my understanding that this will utilise a local port for this socket, and can anyone clarify which port it decides to use? Is there a way to control which local port the socket is opened on?
This will just create an AF_INET (ipv4) socket that does TCP. Once you call connect it will bind to a port, if not already done so via bind. If you want to pick a port number yourself, just bind manually.
Use bind to control which local port you use. You can optionally also use it to choose which network interface to use.
The following code selects port 12345 on all available interfaces
struct sockaddr_in addr;
addr.sin_family = 2;
addr.sin_addr.s_addr = INADDR_ANY;
addr.in_port = htons(12345);
int err = bind(socket, (struct sockaddr*)&addr, sizeof(addr));
If you don't care which port you use, port 0 is treated as a special case where the network stack chooses an(y) available port
The freshly created socket does not have an address until you bind(), listen(), or connect() it.
If you want to connect() or listen() on that socket, you don't necessarily have to bind to an address and port first; one will be automatically assigned. However, if you're trying to run a server that others will connect to you will probably want to first bind() to a known address and port. Sometimes you want to connect out from a particular address and port, and you here you also have to bind() first.
If you want to find the address to which an existing socket is bound, use getsockname().
Read socket(2) and and ip(7) man pages and some tutorial on Linux sockets. You also need to call the bind(2) syscall to bind to some particular port.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 4 years ago.
Improve this question
Im playing with 'recvfrom' and 'sendto' calls using UDP.
I have a client that just broadcast UDP packets on port 6000.
I have a server that binds a socket on port 6000, and do a single recvfrom.
The problem is that sin_port member of struct sockaddr returned from recvfrom is always incorrect. Why?
I would post some source code but someone already posted that question (with no answers) and I'm using almost the same code as he. Besides, you can get further information about this problem reading his post: FORUM POST.
Thanks in advance
EDIT: I really think 'cause number 2' from 'nos' answer might be the problem. How can I check it?
Here's 2 likely causes:
You're not converting the sin_port to host order before you inspect/display it. sin_port comes in network endian. That is you might be displaying the port as big endian on a little endian machine.
Your client uses a random source port. So while your destination port is 6000, the source port of the client is randomly chosen. recvfrom gives you the source IP address and the source port no. Not the destination port.
If it's neither of these, please provide some relevant test code, and the actual values you are seeing. It's possible you e.g. have some buffer overflows, or something other fishy going on.
EDIT, looking at the code in your link, you hardcode the buffer size(udpPkg.udpRecvBuf) as 1024. Is the buffer really atleast 1024 big ? If not, you're probably overflowing udpPkg.udpRecvBuf.
Are you converting from network byte order?