Member Avatar for kid.coder

Hey i was just writing a simple server i'm using accept() in a loop to emit constant greeting but i dont know why my code stucks at single send() i mean it asks for input only once --> it asks for input --> i give input--> it emits succsfully to port 3490 or whatever in my code ---> but it does not asks for another input even though my code is in a loop Help me there check out my code -->

#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>
#include <arpa/inet.h>
#include <netinet/in.h>


# define BACKLOG 5

int main(int argc,char *argv[]){


    int status,socket_result,new_fd;
    struct addrinfo hints,*result;
    struct sockaddr_storage their_addr;
    socklen_t addr_size;



    memset(&hints,0,sizeof hints);


    hints.ai_family = AF_INET;
    hints.ai_flags = AI_PASSIVE;
    hints.ai_socktype = SOCK_STREAM;


 status = getaddrinfo(NULL,"3490",&hints,&result);


socket_result = socket(result->ai_family,result->ai_socktype,result->ai_protocol);



if(socket_result == -1){
    printf("server might be alrey running");
    return 1;
}

bind(socket_result,result->ai_addr,result->ai_addrlen);


while(1){

char data[13];

listen(socket_result,BACKLOG);

addr_size = sizeof their_addr;

new_fd = accept(socket_result,(struct sockaddr *)&their_addr,&addr_size);
printf("enter input \n");
scanf("%s",data);
printf("about to send your input");
send(new_fd,data,13,0);
printf("input sent");}





return 0;



}
  • 2 Contributors
  • 4 Replies
  • 669 Views
  • 3 Hours Discussion Span
  • Latest Post Latest Post by L7Sqr

Dani AI

Generated

Quick diagnostic summary and practical fixes that build on 's comments and address 's symptom.

The symptom ("send() appears to hang after one send") most often comes from one of these: blocking syscalls (accept/read/send) hiding where the program actually waits; writing to a socket whose peer has closed (which can generate SIGPIPE or errno like EPIPE); or misuse of fixed-size buffers and lengths (sending exactly 13 bytes regardless of the string). Also several system-level safeguards and resource-handling bugs make the problem worse (no checks for return values, listen/accept in the wrong place, not closing descriptors after fork).

Practical checklist (quick to run):

  • Always check return values for getaddrinfo/socket/bind/listen/accept/send and inspect errno with perror/strerror when a call fails.
  • Never send a fixed 13 bytes; send the real length (e.g. use strlen(buf) or include the terminating NUL only if protocol requires it).
  • Replace unsafe scanf("%s",...) with fgets() or getline() to avoid overflow and to permit spaces/newlines.
  • Prevent process termination on write-to-closed-socket with signal(SIGPIPE, SIG_IGN) or use send(..., MSG_NOSIGNAL) on platforms that support it.
  • Use setsockopt(SO_REUSEADDR) before bind, and call listen() once (not each loop). After accept(), fork (or thread) to handle the client; parent must close the accepted socket, child must close the listening socket and exit when done. Reap children (SIGCHLD or waitpid) to avoid resource issues.
  • If behavior is still unclear, run a syscall tracer (strace -f) to see precisely whether the process is blocked in send, accept, or waiting on stdin.

Minimal server skeleton (child-handling and safe send):

/* after socket(), bind(), setsockopt(), listen() done once */
for (;;) {
  int conn = accept(listenfd, (struct sockaddr*)&cli, &clilen);
  if (conn < 0) continue;
  pid_t pid = fork();
  if (pid == 0) {
    close(listenfd);
    char buf[512];
    while (fgets(buf,sizeof buf,stdin)) {
      ssize_t n = send(conn, buf, strlen(buf), MSG_NOSIGNAL);
      if (n <= 0) { perror("send"); break; }
    }
    close(conn);
    _exit(0);
  }
  close(conn);
}

Key outcomes: check send's return and errno, avoid fixed-length sends, ignore SIGPIPE or use MSG_NOSIGNAL, and keep listen() outside the accept loop while properly forking and closing descriptors. These changes reveal whether send truly blocks (rare for small writes) or whether some other blocking call or signal is responsible.

Recommended Answers

All 4 Replies

Member Avatar for L7Sqr

The next time you loop through you are calling listen and accept again. First, I would move the listen outside of the loop. Second, accept is a blocking call - that is, if no other connection attempts are made it will wait there indefinitely.

A general approach to this situation is to fork a child to handle the newly accepted socket or to use a thread instead of a new process.

Member Avatar for kid.coder

Hey I got it about using fork() but in case of listen() n accept() im confused cause compiler cursor should move down after send() and should printf("input sent"); but it seems to be freezed at send() i mean send is not returning anything.

Member Avatar for kid.coder

or can you please modify my code for fork part it would be great help thanks

Member Avatar for L7Sqr

I'm not sure what a compiler cursor is - I'm assuming it to be the prompt on your terminal?

Can you print the return value from your send call (it returns a value you should be reading). Instead of printf, however, use fprintf to stderr.

I suspect that you are running into a buffering issue that is complicating the problem for you. printf is a buffered output statement meaning that it isn't necessarily sent directly to the screen when it returns. To overcome this you can issue an fflush (stdout) after the printf or you can use fprintf (stderr, ...) instead.

Try replacing all your printf statements with fprintf (stderr, ...) and see if that changes things for you.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.