TCP/IP DataInputStream reads not all data send in one time?

Question

I have a C program that sends 4104 bytes of data to a java client.
In my java client I have a buffer of 4104 bytes that reads the data using a DataInputStream. Now my problem is that the read function returns with only 1460 bytes instead of 4104 bytes.
I only have this problem on a new type of PC we are using.
Now I was wondering when you have a TCP/IP session doesn't every send results in 1 recv (read)?
Does this differ for various platforms? (is that buffer size adjustable)
Thanks!

Answer 1

Alright then I do have a problem.
If your application level doesn't define a blockthen
you have problems.So I have to keep reading on the socket untill I get a
timeout? I saw that DataInputStream has a function
available(), this should return the available number
of bytes that can be read without blocking. This
hardly seems to work?
I just want to read 1 TCP packet without knowing the
size or the protocol of the packet without having to
wait for some timeout. I don't want to reassemble -
defragmentate all my packets. This question seems very
reasonable to me, but perhaps I'm missing something?
There's no guarantee in TCP that a block size N
written in one application will be delivered as a
single block to the receiver.Is there a place I can read that specification?Usually people need to understand an API in order to be able to use it. TCP sockets present a continuous stream paradigm: the data stream starts when the connection is established and ends when the connection is closed. Now reread your own question: you want to read a block of data from such a stream without knowing the size of the block. That just makes no sense. It is like trying to read first X bytes from a file stream without actually knowing what X is. The number of bytes available immediately on a socket read is subject to all kinds of random factors on the network and has nothing to do with the amount of data the server is actually trying to send as a "block". That is, a single write() on the server does not necessarily correspond to a single read() on the client.
A common solution to this problem is to have an implicit block size (that is, it is fixed and known apriory) or prefix your payload with the block size. An example of the latter would be to send the block size as the block header (say, an int in network byte order) so that the receiving end could read the size first and then perform a loop that continuously reads from the socket until it reads exactly the required amount.
In other words, TCP sockets just provide you with a continuous stream paradigm. You need to impose some kind of an application protocol on top of it to build client-server dialogs. This is what's done behind the scenes by CORBA, RMI, HTTP etc.
If you need to read up on Berkely socket API specifically, Richard Stevens has written some excellent books.