TCP with readByte()

[palmis]

Hi,
I want to receive, by tcp/ip protocol, a stream that is a message with
specific field of specific dimension (some of 2 byte, other of 4 byte
and so on......)
I want to read it byte to byte. How can I do?

This is TCP/IP client code



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

public class TCPServer {
public static final int PORT=7777;
public void start() throws IOException {
ServerSocket serverSocket = new ServerSocket(PORT);

while (true) {
Socket socket = serverSocket.accept();

DataInputStream is = new
DataInputStream(socket.getInputStream());
DataOutputStream os = new
DataOutputStream(socket.getOutputStream());
while (true) {


byte userInput=is.readByte();

???????? How can I control the end of stream
?????????????


os.close();
is.close();
socket.close();
}
}
public static void main (String[] args) throws Exception {
TCPServer tcpServer = new TCPServer();
tcpServer.start();
}
}


Palmis

 

[Sanjay]

Well I know from the basics of TCP/IP that by default protocol will
buffer the application data to reduce the high overhead that occurs in
delivering when segments contain only a few data octets.

But there is a way this can be handled, that is using the push
operation that an application program can use to force delivery of data
currently in the stream without waiting for the buffer to fill.

I am not sure how this can be done in JAVA. Would be very interested to
know.

 

[Roedy Green]

byte userInput=is.readByte();

???????? How can I control the end of stream
?????????????

You likely want a DataInputStream or a LEDataInputstream if you have
little endian.

See http://mindprod.com/applets/fileio.html
for sample code. Tell it you have a socket and binary data.

 

[Thomas Fritsch]

DataInputStream is = new
DataInputStream(socket.getInputStream());
DataOutputStream os = new
DataOutputStream(socket.getOutputStream());
while (true) {

byte userInput=is.readByte();

???????? How can I control the end of stream ?????????????

It is described in the API doc of DataInputStream#readbyte. Look at
<http://java.sun.com/j2se/1.4.2/docs/api/java/io/DataInputStream.html#readByte()>
Quoted from there:
Throws:
EOFException - if this input stream has reached the end.

(The same holds for all the other readXXX() methods of DataInputStream)

Therefore you could write something like this:
try {
....read from DataInputStream
}
catch(EOFException e) {
// stream has reached the end
...do something special
}

BTW: It is a good idea to add <http://java.sun.com/j2se/1.4.2/docs/api/> to
the favorites of your browser. You will need it every day.

 

[Sanjay]

Well I know from the basics of TCP/IP that by default protocol will
buffer the application data to reduce the high overhead that occurs in
delivering when segments contain only a few data octets.

But there is a way this can be handled, that is using the push
operation that an application program can use to force delivery of data
currently in the stream without waiting for the buffer to fill.

I am not sure how this can be done in JAVA. Would be very interested to
know.

I was pointing to this feature of TCP / IP because I was thinking that
the message stream that the program is sending might be broken due to
the above mentioned feature.
Can someone tell me if that wouldnt happen here.
Would this feature make sure that the data that is being buffered will
not be broken, which would make the recieving program interpret
differently.

 

[Thomas Weidenfeller]

I was pointing to this feature of TCP / IP because I was thinking that
the message stream that the program is sending might be broken due to
the above mentioned feature.

The data stream is "never" broken (cutting the wire would of course
break it). Any TCP application that assumes a fixed record size by
assuming "one segment == one record" is broken. Badly. TCP is a
streaming protocol and pushing a TCP segment does not change this. Your
receiving side has to be aware that it gets a data stream, always. And
the application software has, if desired, to separate the stream into
records or messages, or whatever, using higher layer protocols, above TCP.

Take HTTP (which runs on top of TCP) for example. It applies multiple
techniques to separate the data "records" in a message. Headers and body
are separated by an empty line (two CR/LF). Each header line is
terminated with a single CR/LF. A header identifies the body length, or
the message is marked as complete by simply closing the connection.

Can someone tell me if that wouldnt happen here.
Would this feature make sure that the data that is being buffered will
not be broken, which would make the recieving program interpret
differently.

The only thing that is broken would be an application which relies on
particular segment sizes.

/Thomas

 

[EJP]

I was pointing to this feature of TCP / IP because I was thinking that
the message stream that the program is sending might be broken due to
the above mentioned feature.
Can someone tell me if that wouldnt happen here.

There is not and has never been a way for the application to set the
PUSH flag in TCP/IP, not in BSD sockets, WINSOCK, Java, or any other
TCP/IP implementation I am aware of.

 

[frankgerlach]

EOFException might be thrown when the other side closes the socket or
when your protocol stack diagnoses a broken network connection.
Normally, any TCP program must define a protocol (which is then layer 4
of the protocol stack), which defines the length of a "record".
An example for record length definition is "\r\n" of http or the
Content-Length Header of http. Sometimes a parser is being used to
identify the boundaries of a "record". For example, in html, everything
is nested between <html> and </html>. Nobody calls a html page a
"record", but it can be seen as a variable-sized "record". Another
popular and powerful "record" demarcation technique is serialization: A
graph of objects knows how to write itself to a data stream and how to
read itself back from a data stream.
So there are four alternatives for a layer 4/higher protocol: 1.)
constant record size 2.) length indicator (the indicator itself is most
probably of a fixed length) 3.) a parser (for example a html parser)
4.) serialization (which uses technique No 1 and 2 and is something
like a parser)

 

[frankgerlach]

In other words: Every application must know how many times it should
call readByte(). THERE IS NO EOF INDICATOR IN THE TCP/IP STACK ! (Of
course, an application can send a byte which is interpreted as "EOF",
but this is completely application-specific !)

 

[Owen Jacobson]

In other words: Every application must know how many times it should
call readByte(). THERE IS NO EOF INDICATOR IN THE TCP/IP STACK ! (Of
course, an application can send a byte which is interpreted as "EOF",
but this is completely application-specific !)

C: SYN
S: ACK SYN
C: ACK

....data flows...

C: FIN <-- well, almost no EOF. See RFC 793 Section 3.5 for more
details, but it boils down to indicating that the sender (C) has no
further data to transmit.

The RFC is somewhat ambiguous on whether or not the other party (S here)
can continue to transmit after receiving a FIN packet.

 

[Thomas Weidenfeller]

In other words: Every application must know how many times it should
call readByte().

No. This entirely depends on the application, and the amount of data it
finds necessary to read.

THERE IS NO EOF INDICATOR IN THE TCP/IP STACK !

Please don't shout, especially if your statement is wrong. Closing or
reseting a TCP connection is a very clear indication of an end of the
connection. May I suggest you read the standards before claiming such a
thing?

Only if you want to use the same connection for more than one activity
in a row, you need to come up with some higher-level protocol. And there
are plenty of them.

/Thomas

 

[Thomas Weidenfeller]

C: FIN <-- well, almost no EOF. See RFC 793 Section 3.5 for more
details, but it boils down to indicating that the sender (C) has no
further data to transmit.

The RFC is somewhat ambiguous on whether or not the other party (S here)
can continue to transmit after receiving a FIN packet.

It can. It can even happen implicitly, even if the application is not by
intention sending any data after seeing the FIN. There may still be
packets on the way (e.g. buffered in some router), the FIN might have
got lost (that's why it is supposed to be ACKed, otherwise it is
retransmitted), etc.

In TCP both directions are actually closed separately (the first with a
FIN confirmed with an ACK, the other direction afterwards with a
FIN+ACK, confirmed with an ACK). You can have a half-open state between
these, where one direction is closed, and the other isn't. It ain't over
until it's over

/Thomas

 

[frankgerlach]

No. This entirely depends on the application, and the amount of data it

finds necessary to read.

Don't we mean the same thing ? Every application must "know" how many
times it calls read()/readByte() ?

If I understand the OP's question correctly, the question is how to
determine the end of a record. This means that multiple records are
being transmitted and the question is how to find the boundaries of the
records. Only if you terminate the TCP connection after each record
there is a "built-in" EOF indicator.

 

[palmis]

I have understood!
I must know the number of times in which I must
call readByte().

1. readByte() it reads always the successive one or I
must increase it?

2. How I can read the fields of my message of 4/6/8
byte?

 

[palmis]

I have understood!
I must know the number of times in which I must
call readByte().

1. readByte() it reads always the successive one or I
must increase it?

2. How I can read the fields of my message of 4/6/8
byte?

thanks
Palmis

 

[Roedy Green]

1. readByte() it reads always the successive one or I
must increase it?

2. How I can read the fields of my message of 4/6/8
byte?

see http://mindprod.com/applets/fileio.html
for sample code.