Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Sockets, readline

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am using sockets for a client/server application. This is on windows using a buffered reader/writer.

The bufferedreader: br = new BufferedReader(new InputStreamReader(clientSocket.getInputStream(), "UTF-16"));
Reading is in a loop with the basic: if ((line0 = br.readLine()) != null) {

In the client:
outToServer = new DataOutputStream(clientSocket.getOutputStream());

String line = "0000\n";
outToServer.writeChars(line);
outToServer.flush();

Every time a key is pressed I send 4 characters to the server as shown above.
The list below shows what happens when I hold the key down. The first column is the time since the
first key press. As can be seen it increases as one would expect (I assume the delay between the
first and second entry is something to do with windows recognizing a key is being held down but I
am not interested in this). The second column is the initial time  and is just a check to make sure
it wasn't being reset.

0 1493597722611
511 1493597722611
521 1493597722611
561 1493597722611
611 1493597722611
621 1493597722611
661 1493597722611
711 1493597722611
731 1493597722611
771 1493597722611
791 1493597722611
821 1493597722611
871 1493597722611
891 1493597722611
921 1493597722611
971 1493597722611
991 1493597722611

This is what I get on the server. All the lines are read but now they come in groups instead
of with  a time delay as it was in the client, I don't want this. How do I get the reader to respond
with a time delay as occurred in the client? I mean how do I get the server to do the read
every time it hits a "\n" ? I can put in sleep call to simulate the delay but I don't think that is a
proper solution.

0 1493597725270
501 1493597725270
501 1493597725270
501 1493597725270
501 1493597725270
501 1493597725270
501 1493597725270
703 1493597725270
703 1493597725270
703 1493597725270
703 1493597725270
703 1493597725270
703 1493597725270
703 1493597725270
903 1493597725270
903 1493597725270
903 1493597725270
 
Marshal
Posts: 3150
466
Android Eclipse IDE TypeScript Redhat MicroProfile Quarkus Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

leigh matheson wrote:All the lines are read but now they come in groups instead of with  a time delay as it was in the client, I don't want this. How do I get the reader to respond with a time delay as occurred in the client?


When using TCP, data is transferred between endpoints in a stream of bytes.  Each time you write to the socket, the bytes are inserted in to a buffer, and a some point (after buffer full, or timeout, or flush, etc.), the contents are buffer are transmitted through the network to the socket on the other side.  Eventhough you are calling flush after each write sequence, there is no guarentee that a packet will go out each time.  Also, travel time through the Internet can vary widely, so even if you did mange to get a packet sent each time, the timing would not be reliable.

I wrote a simple client/server application similar to what you described and tested between a client and server on different hosts, inter-connected through the Internet.  Using wireshark to watch the packets flow over the wire, I found that for my setup, if the period between the writes (with flushes) was less than around 75ms, that there was a good chance that some data would get bundled together and sent in the same packet.



I you want to be sure that a packet is sent over the network for each event, you would be better using UDP rather than TCP.  If you want to preserve the timing between events, in addition to the event-related information, you should include the timing-related information in thr payload as well, and not depend on when the packets actually arrive at the server.
 
I don't even know how to spell CIA. But this tiny ad does:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    Bookmark Topic Watch Topic
  • New Topic