Convert from integer to ascii...

[HouseMD93]

I am using an integer to receive values from sockets (recv). But i need them as ascii values, but they need to be able to go higher than 255, which is the reason i cannot use char for the recv.

So i get rly huge numbers for a ascii value of 2 (1145330433 in int) and i don't know how to convert between them :/

Could someone help me?

[hoxsiew]

You're as vague in this thread as you were in your previous attempt to convey what it is you are trying to accomplish.

I can appreciate that English may not be your first language, but your terminology makes little sense of the situation. The simple fact is that send() and recv() deal with arrays of bytes (chars). The byte array can represent many different things and is protocol dependent. You can't just cast an array to something else and expect it to magically give you something the protocol was not designed to provide.

You need to provide us with a more information on the nature of the data being received. What is it that the sender is sending? How many bytes are you requesting (parameter 3 of the recv() function) and how many are you receiving (this is the return value of the recv() function)? Do you know anything about the process sending these data?

[HouseMD93]

Ok i try to provide more info, but i am not sure why you would need more. Anyway, here goes:

The sender is sending information like this: mertea (for example) and each number of those letters means something, m being 109 which could represent "Client dies" and the rest could represent the name, or it can represent ip and many other things depending on what the letter is. Of course some letters will have an int of 0 which would make it hard for me to display them here.

That was when i was using a char to receive the characters. Now that i am using integers, i get rly large numbers representing the same characters which do not make any sense to me and makes it hard for me to convert to these numbers or back.

The reason why a range of 255 was not enough is because i am working with chars that represent numbers above 255 and therefore, its impossible to interpret chars representing 1000, for example.


So now, i am stuck with large numbers which i cannot interpret. I converted them back to char with (char *)&buffer when sending the message to my process command. Although only 1 part uses these large chars, it is essencial for the program. so it would be nice to be able to convert chars of over 255 from a 10 digit number to "normal" or vice versa so i could interpret them!

As for the parameter 3 of recv function, i use a large numbers to make sure it can receive the data properly. I am sure i could limit the buffer to the max value. Currently i am using 9000 xD and i do sizeof(buffer) in para3 of recv.

As for the return value... It can be very different, if it has 1 client in the server, recv would get 27 (if the name would be -LZ-HouseMD). Of course it would increase/decrease depending on the name and if there are more than 1 person in the server. This message is not connected to the the chars with an int of over 255. (The server sends alot of messages, and if it helps i am using a UDP socket).

[hoxsiew]

A char is a byte. It has 8 bits. It can't represent values outside of a range of 2^8 (256) . An int (on 32 bit platforms) is a 32 bit integer. It is 4 bytes long. An int and a char are two different things, although an int can be sent as 4 bytes (chars). If you're expecting and int, you need to read 4 bytes, then cast to int (alternatively you can read directly into the address of an integer but you still read 4 bytes from the socket).

int i;
char buffer[4];

recv(socket,buffer,4,0);  //read into a char buffer
i=*(int *)buffer;  //cast buffer to an int pointer, then dereference it.

//or :
recv(socket,(char *)&i,4,0);  //read directly into i's memory address

Also, if you're using UDP, aren't you using recvfrom() instead of recv()?

[HouseMD93]

I used connect to bind the ip address and port to the socket, so i wouldn't have to use recvfrom but just recv.

Anyway, i did the second one: recv(socket,(char *)&i,sizeof(i),0) already which gave me that problem. Except i used int *i[9000] for example. btw does the 3rd para of recv determine what byte it should have or the size?

I have problems understanding the 1st method... (I get recv but what should the cast to int give me?)

[hoxsiew]

The third parameter tells the TCP/IP stack how many bytes you are expecting the sender to send. If you want to read an integer (4 bytes), you request 4. The recv() call may or may not actually send you that many so you have to check the return code of recv() to ensure that all bytes were read.

int *i[9000] allocates memory for 9000 pointers to int, not 9000 ints (although on 32 bit machines, this accidentally ends up being the same since pointers are 32 bits as well) so you got a problem there already. If you want to fill an array of ints, you could do it all in one shot, but a more intuitive way would be in a loop:

int iarray[500];
int i,count=500;
int rc;

for(i=0;i<count;i++){
  rc=recv(socket,(char *)&iarray[i],4,0);
  if(rc!=4){
    //check for error, etc.
    break;
  }
}

Now you should have an array of integers.

Keep in mind that many protocols send data in "network" byte order which is big-endian so the bytes in an integer will be reversed on a little-endian (intel, etc.) machine; so if you have a value of say 1000 as a 4-byte integer, it looks like this in memory:

00 00 03 E8  //big-endian or "network" byte order

E8 03 00 00  //little-endian

If you know that the sender is doing this, you must use ntohl() to convert it:

int iarray[500];
int i,count=500;
int rc;
unsigned long tmp;

for(i=0;i<count;i++){
  rc=recv(socket,(char *)&tmp,4,0);
  if(rc!=4){
    //check for error, etc.
    break;
  }
  iarray[i]=(int)ntohl(tmp);
}

[HouseMD93]

Thanks for the info. Btw, by doing setting the limit to 4 each time, Wouldn't that mean i will not know the end of the message; Assuming i get, for example, 2 messages sent to me at once?

The way i understand it is: by setting the 3rd para of recv to 4, you would receive 1 number not the whole thing (of course) so how would i know if the message is.. you know, over and that its going to another message right now. Cause interpreting a message to be 2 is much different than interpreting the message to be 18, if you see what i mean.

[HouseMD93]

Weird... Doing it like that, i get a bunch of -1's for recv (I am using select command to detect if its time to receive) and sometimes 2 and 1 etc... So i am not sure whats going on...