Re: Repeated read From Socket is Truncated
- From: Eric Sosman <Eric.Sosman@xxxxxxx>
- Date: Thu, 02 Feb 2006 13:12:48 -0500
Trouble@Mill wrote On 02/02/06 12:35,:
On 2 Feb 2006 08:53:32 +0100, Gordon Beaton <not@xxxxxxxxx> wrote:
Your client read() will indicate EOF when the server closes() or does
shutdownOutput() to the connection. If that isn't happening, it seems
to indicate that the server expects to use the connection for more
messages (or it's broken).
Yeah. It's what I'd say is a "normal" client-server connection. The
client connects, sends a request, waits for response, processes
response, decides what to do next, either remain connected to do more
work, or disconnect. It NEVER expects the server to disconnect. It's
just that Java doesn't recognize when that response is complete, and
to return control back to the client code.
If that's the case, then you need to be able to *recognise* when
you've received a complete valid message by looking at the contents of
the data. If there is no clear way to do that, I'd say your protocol
has been poorly designed.
Quite the opposite. I'd say that a protocol that relies on "data
content" to know when a transmission is complete is the poorly
designed one. The socket protocol, for TCP, *DOES* know when the
transmission is complete, and *DOES* signal that to the client. It
works perfectly in C using recv(). That continues to receive data,
until the complete message has been accepted, and then it signals
completion, so the code can then process what it's just recieved. Why
can't Java do that.
Java can't do it because C can't do it, and neither
can C++ or Python or COBOL or APL or assembly language.
What you fail to realize (don't feel ashamed; many
others before you have failed to realize it) is that TCP
provides a byte stream, not a message stream. The only
two "boundaries" in a byte stream are the beginning and
the end. There is no "end of request" or "end of response"
marker in the byte stream. There is nothing to divide
byte N from byte N+1, or to say that they belong to
different "messages."
Contrary to your assertion, TCP does *not* know when
the transmission is complete. As long as the connection
continues to exist, there is the possibility that either
side could suddenly decide to generate some more data,
and this data is in no way separated from what's gone
before -- it's just the N+1st, N+2nd, ... bytes that
follow the N that have already been sent. The only way
TCP can know that there's no more data forthcoming is
when somebody closes his end of the connection.
So: If you want to send multiple "messages" or
"transactions" on a single TCP connection, you need to
arrange some kind of convention to indicate where the
logical divisions in the continuous byte stream occur.
Some common conventions are
- All messages consist of a fixed number of bytes.
The receiver keeps reading until N bytes have
arrived, at which point it knows it has received
a complete message.
- Messages are of variable length, but each is
preceded by a fixed-length count. The sender
transmits "Here comes an N-byte message" followed
by N message bytes. The receiver reads the
fixed-length N value and then reads N more bytes.
- Messages are of variable length, but each is
followed by some kind of "sentinel" to mark the
end of the message. (Obviously, the "sentinel"
must be something that cannot appear as part of
the message "payload.") The sender transmits
the message bytes followed by the sentinel, and
the receiver just keeps on reading until the
sentinel is received.
There are, of course, about a bazillion variations
on these themes.
If you want a protocol that has built-in boundaries,
there's no shortage: UDP is one such, and others exist.
But TCP is not such a protocol, and you will never get
anywhere trying to treat it as such.
--
Eric.Sosman@xxxxxxx
.
- References:
- Repeated read From Socket is Truncated
- From: Trouble@Mill
- Re: Repeated read From Socket is Truncated
- From: Gordon Beaton
- Re: Repeated read From Socket is Truncated
- From: Trouble@Mill
- Re: Repeated read From Socket is Truncated
- From: Gordon Beaton
- Re: Repeated read From Socket is Truncated
- From: Trouble@Mill
- Re: Repeated read From Socket is Truncated
- From: Gordon Beaton
- Re: Repeated read From Socket is Truncated
- From: Trouble@Mill
- Repeated read From Socket is Truncated
- Prev by Date: Re: Repeated read From Socket is Truncated
- Next by Date: Re: accessing objects in JNI
- Previous by thread: Re: Repeated read From Socket is Truncated
- Next by thread: Re: Repeated read From Socket is Truncated
- Index(es):
Relevant Pages
|
