UDP data convert from string to float or int?

I am currently working on a networking project and I am having trouble and I cant seam to find an answer.

First I send a udp packet from the client to the server:



Say that "data" is a variable containing a string.

Now the server recieves the udp packet:




the variable "buf" holds the string recieved in the packet.

Now say buf = "0.1f,0.1f,0.2f" (A set of float coordinates in Opengl)

How can I take the string in "buf" and put the three seprate floats into three variables as floats. Like this:

Original string in "buf":

buf = "0.1f,0.1f,0.2f"

into,

Three seperate opengl floats:

x=0.1f
y=0.1f
z=0.2f

Make sense?

If any one has any ideas or suggestion on how to do this it would be a huge help.

Thanks

Use sscanf() to separate the strings into 3 floats. In your case, the code would go something like this:

Hope this helps

It's actually very easy to do. Just parse that string like you would if you had read it from a disk file or a user typing it in.

A lot of people here seem to like sscanf(). I never use it because in our C class nobody could get it to work right, so I've shied away from it ever since. I'll take a stab at it and let somebody else tell you what's wrong with it:

EDIT:
Please disregard my attempt at sscanf. I ran a test program and it only converts the first field. Scorpion's example does work. If you are not familiar with sscanf, then you might want to ask him how his format string works. I'm going through the scanf man page now to figure it out for myself.

EDIT2:
My sscanf problem was due to the trailing f's. This one does work:

Like I've said here before, I'm learning a lot on this forum.


In our embedded project here at work, we use strtok a lot. Here's how I would do it:


BTW, I recently learned that if you send binary data, then you are subject to differences in byte order. Plus, if you send a struct across as a block of binary data, then you are subject to system differences in byte alignment and padding. Therefore, if you are going to send binary data, you must define an exact format for the data, including number of bytes per field and the byte order (should be network order anyway). Then you will need to explicitly put each field of your struct into the packet and explicit read it out on the other end.

Of course, your use of a character string is one way to get around this problem.

Thanks Scorpions4ever that code did the trick. I even ran it thru some OpenGL code to check it liked the floats.







lol...I didnt realize that there was another way to do it. That was one thing I wasn't able to grasp from the online tutorials on winsock(cant afford the book). How does the recieving socket know what the packet is? like a string or a float? I mean I use this function to send




Can I say



and then send data as an array and the other side treat it as an array? I thought you had to send stuff as strings....

nope you dont have to send strings, u just have to cast whatever you send. you could do:

struct data{
int x
char y
DWORD m
float h} message

sendto(sock,(char *)message,sizeof(message),0,(struct sockaddr *)&server,sizeof(struct sockaddr));

Not quite. That would only work if both ends of the connection are the exact same architecture. If both ends are different architecture (<sarcasm>whenever would that happen on the Internet?</sarcasm>), then three things will very likely bite you hard:
1. Byte order (what Jon Snader calls "byte sex"). Host order could very well not be the same as network order. That's why you need to set the address struct's port with htons(). You will need to do the same for the binary data. The terms "big-endian" and "little-endian" describe the two possible byte orders.
2. sizeof(int). The size of the int type is implementation dependent. That means it could be 16 bits or 32 bits or even 64 bits.
3. Byte alignment. an int will normally be aligned with the data bus, which could be 16, 32, or 64 bits wide. This will affect the alignment of the fields within the struct, such that there could very well be extra bytes of padding between fields. Therefore, the "same" struct on different architectures could be different sizes and fields therein could get misread.

Case in point of #3: For our first Linux file manipulation program, I started working on it on a Windows 98SE machine, then copied the files over to a Linux box to finish it. That included a data file of structs which I just could not get to work right. Upon examination, I found that the filesize was wrong. I deleted it and recreated it under Linux. This time it worked and the filesize was correct.

That is why I wrote:


You should find examples of such format definitions in the NTP (Network time Protocol -- RFC 1769) RFCs and others.