Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / January 2006

Tip: Looking for answers? Try searching our database.

TCP with readByte()

Thread view: 
palmis - 12 Jan 2006 15:43 GMT
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 - 12 Jan 2006 18:21 GMT
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.
Sanjay - 13 Jan 2006 05:26 GMT
> 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
[quoted text clipped - 6 lines]
> 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 - 13 Jan 2006 08:58 GMT
> 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
Signature

The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/

EJP - 15 Jan 2006 09:25 GMT
>>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
[quoted text clipped - 7 lines]
> 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.
Roedy Green - 12 Jan 2006 21:51 GMT
>                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.
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Thomas Fritsch - 13 Jan 2006 01:28 GMT
>             DataInputStream is = new
>                  DataInputStream(socket.getInputStream());
[quoted text clipped - 5 lines]
>
>    ????????    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.

Signature

"TFritsch$t-online:de".replace(':','.').replace('$','@')

frankgerlach@gmail.com - 16 Jan 2006 00:29 GMT
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@gmail.com - 16 Jan 2006 00:37 GMT
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 - 17 Jan 2006 04:16 GMT
> 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 - 17 Jan 2006 08:22 GMT
> 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
Signature

The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/

Thomas Weidenfeller - 17 Jan 2006 08:01 GMT
> 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
Signature

The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/

frankgerlach@gmail.com - 17 Jan 2006 19:03 GMT
>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 - 23 Jan 2006 11:31 GMT
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 - 23 Jan 2006 12:01 GMT
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 - 23 Jan 2006 21:07 GMT
>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.
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.