Thread: sending byte <= -112

Originally Posted by slingerland3g

In analysis

First pass,

send will return 1

sent = 1

Second pass

send will return 2

sent = 3

No, that cannot happen.
If send() returns 1 on the first pass, then send() cannot return 2 the second pass. send() returns the number of bytes sent. On the second pass, the third parameter to send() will be 1, so the maximum number send() can return is 1 -- not 2.

Hello everyone.

I'm a bit rusty with java streams, but according to the doc, InputStreamReader is a bridge from byte streams to character streams. Since the sender is dealing with bytes, the receiver should do the same. This java receiver behaves as expected:

Code:

import java.net.Socket;
import java.io.*;

public class x {

    public static void main(String[] args) {
        try {
            Socket s = new Socket("127.0.0.1", 55555);
  
	    InputStream isr = s.getInputStream();
	    int r;
	    while((r = isr.read()) != -1) {
		if (r >= 128) {
		    r |= 0xFFFFFF00;
		}
		System.out.println("read: "+ r);
	    }



        } catch(Exception e) {
            e.printStackTrace();
        }
    }
}

The input stream returns a value between 0 and 255 with -1 indicating end of stream. Anything over 128 needs to have the sign extended.

Is there a better way? I don't know.


On the sender:

Code:

    SOCKET conn = accept(s, &saddr, &size);
    char wbuff[30];
	int ix = 0;
	wbuff[ix++] =  1;
	wbuff[ix++] =  0;
	wbuff[ix++] =  -1;
	wbuff[ix++] =  -2;
	wbuff[ix++] =  -3;
	wbuff[ix++] = -111;
    wbuff[ix++] = -112;
    wbuff[ix++] = '\r';
    wbuff[ix++] = '\n';
    send(conn, wbuff, ix, 0);

The receiver prints
read: 1
read: 0
read: -1
read: -2
read: -3
read: -111
read: -112
read: 13
read: 10

You are correct Zlatko. Java uses 16 bit characters, and it expects it's strings to be serialized to UTF-8. This means that if you are sending bytes, you should receive bytes as Zlatko has done in his code example.

@Cactus_Hugger: On my windows XP OS, it printed a question mark.

Anyways, as to the thread, it is as Zlatko described it. The internal string conversions were causing the problem. Turns out to be, I was wrong after all; the problem lied within the client. :P

Thanks again!

The problem was client-sided, actually. I just finished fixing it. I did not intend to treat the received byte(s) as characters, I simply wanted to read from the stream line-per-line. I did not know that this automatically converted the read bytes into characters.

Anyways, to fix the problem, I made my own line-per-line reading method and treated each byte as a byte, and not as a character.

I also couldn't find anything in the Java docs as to what character set BufferedInput uses while reading the file.

You can specify the character set to expect in the InputStreamReader class. If this is not specified, it will use the platform's default character set (which is probably UTF-8).