Thread: Sendto/Recvfrom -- something fishy

  1. #1
    Eager young mind
    Join Date
    Jun 2006
    Posts
    342

    Sendto/Recvfrom -- something fishy

    I am not able to explain whats been happening here for the last 45 mins or so.. I thought of posting it here:

    this is my client code :

    Code:
         if (0 > sendto(sd,buf,strlen(buf)+1,0,
                           (struct sockaddr*)&server_addr,
                           sizeof(server_addr))){
                    perror("Client: Failed to send");
                    exit(1);
            }
            printf(" sent message = %s\n",buf);
           if (0 >= recv(sd,buf,sizeof(buf), 0)){
                    perror("Unexepected response");
                    exit(1);
            }
    The sendto returns and the printf statement is executed and the client hangs.

    this is the corresponding server code ;

    Code:
     if (0 >= recvfrom(sd,inbuf,sizeof(inbuf), 0,
                        (struct sockaddr*)&client_addr,
                        &alen)){
              perror("Unexepected message");
      }
      printf("Server: Message received: %s !\n", inbuf);
      if (0 > sendto(sd,outbuf,strlen(outbuf)+1,0,
             (struct sockaddr*)&client_addr,
                     sizeof(client_addr))){
              perror("Server: Failed to send");
      }
    recvfrom() is not returning.
    Everything prior to this seems to be fine,I have done error checking at required places.

    Also, the same thing works when I launch the server and the client on the same machines. Which means the client is not able to reach the server, when i run them on different machines. Is that right? But, the addresses must be valid.
    In the middle of difficulty, lies opportunity

  2. #2
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    Are you sure the string in buf is zero terminated?

    what addresses are you using when you run them on the local machine, remote machines?

    I see you arent doing error checking on the return value in the case where sendto() returns SOCKET_ERROR. The results from a WSAGetLastError() might enlighten you as to the problem, it may also offer the oportunity to gracefully recover from the error.

    Also, are you sure you are performing the startup sequence for the socket properly?
    Last edited by abachler; 05-31-2007 at 09:22 AM.

  3. #3
    Eager young mind
    Join Date
    Jun 2006
    Posts
    342
    Thanks for that. Figured that out. I forgot to add that the socket belongs to the family, AF_TIPC and there was some problem with TIPC when i posted that. So, that problem is now fine.
    But, I seem to be having a rough day with calls like these not returning. Its now with read() and write(). Its so simple, yet i am not able to get them right. I dont know if i am really missing something or its something else... Take a look:

    * I AM using SOCK_STREAM sockets.
    * On the sender side, the write() has completed and has returned the number of bytes sent.
    * On the receiver side, the read() has no plans of returning and hence my application hangs at that stage..
    * I have used a send() and recv() pair prior to this, and things have worked as expected.

    Code:
    if( flag ==1 )  // sender
    {
       char s[] = "SyncMe";
       int num;
       num=write(p->commfd, s, strlen(s));   //valid socket descriptor.. checked!!
       printf("return value of write :%d\n",num);
       .................
       .................
    }
    
    else           //receiver 
    {
       char *buf;
       buf=malloc(sizeof(char)*10) ;
       int num;
       num=write(p->commfd, (void *)buf, strlen(s));  //hangs here. 
       printf("return value of write :%d\n",num);        // not executed
       .............................
       .............................
    
    }

    It just occurred to me, that I am not stuffing in the '\0' before i call write(). Is that the problem? Anyway, I cant test the program for the next few hours.
    In the middle of difficulty, lies opportunity

  4. #4
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    yes, printf() generally wants a \0 at the end of a string so it knows when to quit.

    also notice you are using write in both sections of that code, and s is undefined for the second section

    if it worked with send() and recv() why did you switch? I use custom versions of send() recv() but only because I added in robust error handling and I dont feel like typing a couple hundred lines for each send() or recv().
    Last edited by abachler; 05-31-2007 at 02:00 PM.

  5. #5
    Eager young mind
    Join Date
    Jun 2006
    Posts
    342
    Yeah, right... I typed the code as I didnt have the actual code with me then. This is what it should have been. Will try that "\n"

    Code:
    if( flag ==1 )  // sender
    {
       char s[] = "SyncMe";
       int num;
       num=write(p->commfd, s, strlen(s));   //valid socket descriptor.. checked!!
       printf("return value of write :%d\n",num);
       .................
       .................
    }
    
    else           //receiver 
    {
       char *buf;
       buf=malloc(sizeof(char)*10) ;
       int num;
       num=read(p->commfd, (void *)buf, 10);  //hangs here. 
       printf("return value of write :%d\n",num);        // not executed
       .............................
       .............................
    
    }
    >if it worked with send() and recv() why did you switch?
    Well, I am trying to port a NETPIPE code that measures the performance for TCP and other protocols to work for TIPC. The write() ,recv() pair works fine in the original source code that was meant for TCP, but its hanging for my TIPC code.
    Last edited by kris.c; 05-31-2007 at 07:56 PM.
    In the middle of difficulty, lies opportunity

  6. #6
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    BTW, when you directly enter the string into a printf, the compiler is nice enough to silently add the /0 at the end

Popular pages Recent additions subscribe to a feed