The reason for this "problem" has nothing to do with the
Java implementation: it is an artifact of the TCP protocol.
TCP is a "reliable byte stream transport protocol" which
means that it guarantees reliable delivery of the data *bytes*
in the order that they were sent, but it doesn't guarantee
how the sequence of bytes is broken up into packets.
Also, the UNIX socket API semantics upon which the Socket
class is founded don't guarantee anything about how much
you're going to read when you ask to read data: you block
until something arrives and the interface gives you as much
as it can up to what you asked for, but can (and will) often
give you less.
Any code -- whether Java or C or C++ or Perl or Tcl or Lisp
or Basic or what have you -- which assumes that TCP will
preserve "message" boundaries in stuff sent over a connection,
is just WRONG. You might get lucky on some platforms
but that will just be a matter of a coincidence that works in your
favor.
Any code using TCP should ALWAYS be written to allow for the
fact that bytes sent can be broken up or coalesced in transit
in any arbitrary way which preserves content and byte ordering.
Assuming anything else is just asking for trouble.
For example if a sending program does 3 writes of 4 bytes each,
it is perfectly valid for that data to be delivered to the receiver
in any of the following ways (and this list does not exhaust the
possibilities):
* as 3 packets of 4 bytes each (matching the sender's message sizes)
* as 12 packets of 1 byte each
* as 1 packet of 12 bytes
* as a packet of 3 bytes followed by a packet of 7 bytes followed
by a packet of 2 bytes
Jeff Radick
nomadic kernel/networking/mathematics sort of guy, for now
[EMAIL PROTECTED]
Re:
-------
> ... (mail header stuff deleted) ...
> From: "Jauvane Cavalcante de Oliveira" <[EMAIL PROTECTED]>
> ... (mail header stuff deleted) ...
> To: Bill Paladino <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED]
> Subject: Re: sockets; data transfer limits
> ... (mail header stuff deleted) ...
> > Has anyone come across a limit on the size of a transfer thru a Java socket?
>
> Yes, I had this problem under Solaris. In my case packets greater than 1500
> bytes was tryncated into 1500, most likely because of the ethernet packet size.
> I submitted such behaviour to Javasoft in their Bug Parade section but they
> said:
>
> "DataInputStream.read does not guarantee that all len bytes are read. It returns
> the number of bytes read and this may not be all len bytes. You may have to
> either loop on a read until you get all the bytes or use readFully().".
>
> Have a look at
> http://developer.java.sun.com/developer/bugParade/bugs/4095603.html
>
> The work around I use is simply the fragmentation of my 2Kb packet into two 1Kb
> ones.
>
> > This is NOT a problem on Windows-95 which I'd rather not use.
>
> Thios didn't use to happen under Windows as well (as noted in my bug report) but
> the point is that under any OS there is no guarantee about it... Too bad heh?
>
> JVc.
> ... (signature stuff deleted) ...
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
