Problems writing a protocol on top of sockets in Java

I'm 开发者_JAVA技巧writing a protocol on top of sockets, so I've decided to implement headers then send the information. So there is one thread per connection on the server which sits there reading in headers, then delegates off to methods to read in the rest of the information when it arrives.

So essentially it looks like this:

while ((length = inStream.read(buffer)) != -1)
{
   dispatch(buffer, length);
}

So the dispatch method then decrypts the headers and delegates the method depending what is found in the header. It looks similar to:

byte[] clearText = decrypt(message,length);
if (cleartext == foo) sendFooToSocket();

So then sendFooToSocket() would then sit there and read from the instream or send to the outstream. This is where I seem to run into some problems, in the client I'm sending the header then flushing, then sending the rest of the data, but it appears it's all coming as one and not being split up into header then data. Also is there a best way to force out of the sendFooToSocket method?

public void sendFooToSocket()
{
  byte[] buffer = new byte[1024];
  int length = 0;
  while ((length = inStream.read(buffer) >0)
  {
    message = decrypt(buffer, length);
  }
}

I would assume flush would allow me to break out of this method as it closes then opens the stream?

So I have 2 problems, flush doesn't seem to be breaking up my messages and flush doesn't seem to be allowing to drop out of methods such as sendFooToSocket(), any suggestions?

For clarity sake, the client just does this:

byte[] header = "MESG".getBytes();
cipher = encrypt(header);
outStream.write(cipher,0,cipher.length);
outStream.flush();
byte[] message = "Hi server".getBytes();
cipher = encrypt(message);
outStream.write(cipher,0,cipher.length);
outStream.flush();

But this is received by the server as 1 message even though it's been flushed after every write. Sending just the header works, and we get stuck in the sendFooToSocket() method, but if I send the data after the flush it comes all at once.

The client uses OutputStream and InputStreams just from the socket.get. The client also uses OutputStream and InputStream. Not sure if this matters?

What you seem to want is "record boundaries". With streams in general there are no implicit record boundaries. If you want that kind of functionality you will need to implement it yourself, by buffering the input and looking for, say, newlines to indicate the end of a record.

Look at BufferedInputStream.

inStream.read() may not be returning on a message boundary. You can't assume that it'll return at any particular boundary (such as a blank line separating headers and content if that's how you're doing it.) You'll have to manually parse the content and ignore the fact that it could come from multiple read()s or maybe one read() contains both the headers and content.

Unless you actually want control at the level you have implemented, you could consider Object streams (see ObjectInputStream and ObjectOutputStream). Such streams will allow you to send Java Objects over sockets and read them at the other end with out having to deal with headers and boundaries etc. See ObjectOutputStream for more details, but it's pretty much:

Sender: writeObject(objectX)

Receiver: myCopyOfObjectx = readObject()

and you can send any objects you like (as long as they are Serializable).