UDP issues

[Brendan Fosberry]

Hi all. Im writing a server for a multiplayer game. Information is sent in packets of 256 bytes. The first 4 bytes of each packet is an integer number representing the ID of this packet. When a packet is send a local copy is stored in a hashmap based on the integer ID. When the server recieves a packet out of sequence it requests a resend of the packet its been expecting which is taken from the hashmap and resent.

The problem is that for certain numbers the id comes out wrong and I cant work out why.

public void send(String s) {
//System.out.println("sending "+s);

//send a message to the server

//init the byte array to be sent
byte[] buf = new byte[buffsize];
//get the byte array of the string to be send
byte[] stringy = s.getBytes();
 
//loop through the message in steps of 'buffsize' (256). 4 bytes are used for an int message id
for (int j = 0; j < stringy.length; j += buffsize - 4) {
//get_id returns the id of the next message. increments in steps of 1
int iday=get_id();
connlog.output_line("id is "+iday);
//function inttobytearray works fine
byte[] id = Connection.intToByteArray(iday);
//this function works ok too
connlog.output_line("converts to "+byteArrayToInt(id));
//first stick in the ID
for (int i = 0; i < 4; i++) {
buf[i] = id[i];
}
//then fill in the rest with the message
for (int i = 4; i < buffsize && (i + j) - 4 < stringy.length; i++) {
buf[i] = stringy[i + j - 4];
}
 
DatagramPacket packet = new DatagramPacket(buf, buf.length,
serverip, port);
int id1 = Connection.byteArrayToInt(id);
connlog.output_line("sending "+id1+" - "+new String(buf));
//store the message as one already sent

prevmessages.put(id1,  new String(buf));

connlog.output_line("saving "+id1+" - "+new String(buf));
//Object o=(prevmessages.get("" + id1));
//System.out.println(o.getClass());

//check it
byte[] buffer = prevmessages.get(id1).getBytes();
byte [] id3=new byte[4];

id3[0]=buffer[0];
id3[1]=buffer[1];
id3[2]=buffer[2];
id3[3]=buffer[3];
connlog.output_line("saved as"+""+byteArrayToInt(id3)+" - "+new String(buffer));
//message id goes up to 99999999, but we only keep 100 at a time, so remove the last one
 
int id2 = id1 + 99999999 - 100;
id2 = id2 % 99999999;
if (prevmessages.containsKey(id2)) {
prevmessages.remove( id2);
 
}
 
try {
 
socket.send(packet);
 
} catch (IOException e) {
System.out.println("IOERROR!: "+e.toString());
 
}
}
}  

One example is for 144. The id is 144, it gets put into the byte array and stored int the hashmap and send. The local copy in the hashmap and the message sent to the server come out as 63. Does anyone have any idea why it might do this?

thanks
Brendan

[Darren Cheong]

I'm going to gout on a limb here and say 144 is beyond the value of a byte?

Recently, in my company we were working on a program that reads a barcode value and decodes it, we run our program on two platforms, one for linux and one for windows and we noticed something strange. The barcode we were reading is referred to using hex values and as such we had one with the hexvalue of 0x81 .. of course 81 is beyond the limits of a byte and will be a negative value in byte which is fine..

The strange thing is how a byte is read by a String class. In Windows the value we entered returned as 63 or a "?" and in Linux it returned as blank. This really only happened after we convert the byte array into a string as we tested the byte array and the values are correct, though negative for values exceeding 127.

In short, negative byte values do not get translated correctly when passed into a String. I think this has to do with the fact that the ascii chart generally reaches to 127 and anything beyond that is platform dependent? Occasionally with negative byte values i get some weird Strings not in the standard ascii char set.

What you can perhaps do is before using it as a hash key is to convert it into a positive short or int value.. thats what we did and might not be the best way to do it

I hope this helps.

Regards

p/s : Sorry if i am not clear, i'm hopeless in explaining things...
[ September 22, 2006: Message edited by: Darren Cheong ]