-1

I can't seem to find a solution to this, most people have the following but this doesn't work for me.

int sock_fd;
int new_fd;
int rc;
char recv_client_msg[100];

rc=read(new_fd, recv_client_msg, sizeof(recv_client_msg));

if(rc>0)
 {
   if(strcmp(recv_client_msg, "s1p1")==0) {printf("s1p1\n"); }
   if(recv_client_msg[0]=="s") {printf("m\n");}
 }     

My sockets are completely functional. When the client is open, if I press the "m" key the program prints "m" on the local terminal. However I want to print "s1p1" on the local terminal when I type "s1p1" when I have the client open. However this doesn't happen despite reading previous examples and the compilation being successful.

Any tips would be appreciated

My theory is it may be something to do with the program processing the first character "s", successfully but when I enter "1" the first "s" is overwritten by the "1" rather than takingg up the second slot in the string.

DA93
  • 11
  • 1
  • 1
    How about adding a `printf( "rc = %d\n", rc );` ? – donjuedo Jun 23 '15 at 11:19
  • What is 'new_fd',is it OK if its uninitialized? – Vagish Jun 23 '15 at 11:19
  • Adding `printf("'%.*s'\n", rc, recv_client_msg);` should tell you what went wrong. – Phillip Jun 23 '15 at 11:20
  • 2
    Make sure you have received at least as many bytes as you intend to process, and if you're comparing strings you'd better make sure they're NUL-terminated, as C strings are. – Michael Foukarakis Jun 23 '15 at 11:21
  • Most people don't have that. The have a loop around the recv() call, assemble the buffer as the bytes come in and check for the terminating '\n'. TCP does not transfer strings or messages, just bytes in a stream. – Martin James Jun 23 '15 at 11:51
  • @Vagish where would i write that printf? By creating an else after the comparison? – DA93 Jun 23 '15 at 11:53

2 Answers2

1

Some notes:

  1. To read/send data over network you need functions such as this and this. Because send and receive not always send/receive how much you told them to.

  2. You seem to use uninitialized variable new_fd which doesn't look nice.

  3. Finally after you have ensured all the data has been received that was sent(using the approach I mentioned in (1)), comparing strings is not issue - you can use just strcmp, assuming strings are null terminated.

Giorgi Moniava
  • 27,046
  • 9
  • 53
  • 90
  • The reason to use `send()`/`recv()` over `write()`/`read()` is that the former take an extra parameter for flags, passing `0` as flags makes them equivalent to the latter. – Iharob Al Asimi Jun 23 '15 at 12:03
  • @iharob: You say if I do read and write and specify say 100 bytes they ensure 100 bytes are sent/received? – Giorgi Moniava Jun 23 '15 at 12:04
  • No, I did not say that! how can you come up with such a conclusion? I just said that `send()`/`recv()` and `write()`/`read()` are not soooo different, just that `write()`/`read()` are like `send()`/`rect()` with a default flags value of `0`. – Iharob Al Asimi Jun 23 '15 at 12:11
  • @iharob: Well yeah but first I didn't grasp probably why that was relevant, hence the comment - anyway .. – Giorgi Moniava Jun 23 '15 at 12:15
  • It's because from the first point in your answer it's not clear why you recommend `send()`/`recv()`, and then it seems that you do so because they can perform incomplete operations. – Iharob Al Asimi Jun 23 '15 at 12:19
  • @iharob: Well yeah.. that would be weird way to interpret what I wrote. I have links specified to what I refer in the first point; "Because send and receive not always send/receive how much you told them to" I even had this. Anyway, edited. – Giorgi Moniava Jun 23 '15 at 12:21
-1

Use memcmp() instead, the strcmp() function requires that both parameters be nul terminated, which is not guaranteed when passing the string through a socket, you can use memcmp() which takes the number of bytes to compare as a parameter.

if (((rc == 4) || (rc == 5)) && (memcmp(recv_client_msg, "s1p1", rc) == 0))
    printf("s1p1\n");

the (rc == 5) test is performed because if the nul termination byte is present, then the comparison should also give true.

Iharob Al Asimi
  • 52,653
  • 6
  • 59
  • 97
  • any particular reason why you have chosen 4 and 5? and isn't memcmp limited to 8 in some way? not that it matters – DA93 Jun 23 '15 at 11:46
  • @DA93 Yes `4` is the number of characters in `s1p1` and `5` is used to include the terminating `nul` byte, and **NO**, `memcmp()` is not limited at all, why would you think that? – Iharob Al Asimi Jun 23 '15 at 11:59
  • unsure, i was looking at memset earlier and i saw something about being restricted in some way but i'm unsure, it might have been a question elsewhere rather than a solution, and how does being nul terminated make it include all 4 characters before the command is proceed? Is my theory above correct in what it's doing if i don't use this? – DA93 Jun 23 '15 at 12:06
  • @DA93 `memset()` is not related to this answer in any way, and it's restricted to bytes, so you can't `memset()` a pointer of double except all `0`s, and I don't understand your new question. – Iharob Al Asimi Jun 23 '15 at 12:13
  • 1
    i have replaced my strcmp command with the memcmp, and nothing happens: i run the program successfully connect to my client, pressing s prints s but memcmp doesnt seem to make a difference. and replace my previous question with memcmp instead of memset, that was a mistake on my behalf – DA93 Jun 23 '15 at 12:23
  • also what i'm asking is: is the code written right, but what is actually happening is: when i press " s" , s is stored but when i press "1". The "1" gets stored but overwrites the storing of the "s" so the s no longer present. therefore the if statement will never be true.. – DA93 Jun 23 '15 at 12:26
  • @DA93 That problem is not caused by this code, please post a new question. – Iharob Al Asimi Jun 23 '15 at 12:56
  • ok, but what what is happening is the s is stored but when the 1 is stored it doesn't store it in the second slot, it overwrites the first slot where the first s is stored, but the if statement is never carried out because the program is expecting "s1p1" – DA93 Jun 23 '15 at 13:02