Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Non-blocking blocking I/O?  (Read 1300 times)
0 Members and 1 Guest are viewing this topic.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Posted 2004-08-15 09:33:07 »

Quote

I have a "not-so-off-topic" question:
Many people claim, that prior to JDK 1.4.0 all IO operations were blocking and there was no way to avoid thread-per-client model. This I cannot really understand, because:

- ServerSocket.accept() really blocks, but it is not a problem, it is possible to have one thread just for accepting new connections, and one thread for handling all existing connections
- InputStream.available() does not block, so it's possible to have non-blocking reads, if you call available() first
- OutputStream.write(byte[]) does not seem to block either, at least as far as I know. In fact it does not provide any output, I've never seen it to throw an exception, even when the connection was closed. I really don't think it blocks. Correct me please, if I'm wrong.
(I'm talking about Socket TCP connection)

I have implemented this, and it seems to work without a problem. I'm thinking of switching to NIO, but I'm not convinced it could bring any real advantage - can someone please try to convince me? Smiley

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #1 - Posted 2004-08-15 09:38:38 »

Quote
I have a "not-so-off-topic" question:
Many people claim, that prior to JDK 1.4.0 all IO operations were blocking and there was no way to avoid thread-per-client model. This I cannot really understand, because:


The only way around this was to use JNI. There were a few asynch/NIO alternatives before 1.4, at least one of which was a major influence on 1.4's design.

Quote

- InputStream.available() does not block, so it's possible to have non-blocking reads, if you call available() first


Read the javadocs for it. InputStream always returns 0 for this method. Do you see a problem Smiley ?

BufferedInputStream simply returns 0 + however many extra bytes it has accidentally read in on the last read and not surrendered yet.

I'm afraid I can't give you a definite answer, because it's so long since I was using I/O, but off the top of my head the available method either returned 0 or "guessed" (this was a known problem and I have a vague memory that Sun used to say it was a "guideline" figure rather than necessarily accurate, because I/O wasn't attempting to provided non-blocking capability).

IIRC this is another example of where the general API allows you to try to do something that a particular implementation won't - InputStream was NOT designed just for networking, and some of it's subclasses can actually return a sensible value for available (not to mention that you want the method in the superclass for type reasons)...but that doesn't mean that just because you have an object of that type and that the method exists that the method will actually be *valid* in that situation.

So, you could call this method, but it had no meaning.

Quote

- OutputStream.write(byte[]) does not seem to block either, at least as far as I know. In fact it does not provide any output, I've never seen it to throw an exception, even when the connection was closed.


Some of us believe this is a fatal flaw in Sun's API design - it cannot throw an exception because it actually doesn't transmit data, it just shunts it onto a queue and then when that data fails it can't get a notification because the API doesn't have callbacks. IIRC a JVM engineer told us that you would get the IOE on the NEXT call to the method, which is insane and stupid and I have trouble believing.

Quote

I have implemented this, and it seems to work without a problem. I'm thinking of switching to NIO, but I'm not convinced it could bring any real advantage - can someone please try to convince me? Smiley


Go to JGF (link in my signature below), go to the articles section, and read the NIO articles. That should convince you...

malloc will be first against the wall when the revolution comes...
Offline Matlu

Junior Duke




Hasta La Victoria Siempre!


« Reply #2 - Posted 2004-08-15 10:48:10 »

Quote

Read the javadocs for it. InputStream always returns 0 for this method. Do you see a problem Smiley ?

Quote
So, you could call this method, but it had no meaning.


I have read relevant javadoc many times  Wink InputStream.available() is really said to return 0, but it is an abstract class. If you call Socket.getInpustStream() you will get an instance, which behaves correctly. I have tried it today with both 1.3.1 and 1.4.1 (from sun for ms windows) and it seems to works fine. As I said before, I have  programmed multiplayer game using this approach, and it works more then just fine.

Quote
Some of us believe this is a fatal flaw in Sun's API design - it cannot throw an exception because it actually doesn't transmit data, it just shunts it onto a queue and then when that data fails it can't get a notification because the API doesn't have callbacks. IIRC a JVM engineer told us that you would get the IOE on the NEXT call to the method, which is insane and stupid and I have trouble believing.

I myself am quite happy with this behavior of "write". I don't mind that write doesn't provide feedback, because if anything went wrong, I will learn about it when I call available() or read(). They *will* throw an exception. I do this at the beginning of each "heartbeat" - so I learn about broken connection fast.
My algoritm is very simple:

while (true)
{
    checkForNewConnections();
      // I have separated 'connector' thread for this
    checkForNewMessages();    // using available & read
    processMessages();
    createStatusUpdateMessage();
    sendStatusUpdateMessageToClients();
   sleep(~500ms);
}

the only problem is, that in extremely bad case (when message is delivered just after checkForNewMessages) it takes 2 heartbeats before response is sent. I think that this could be improved with NIO.

Quote

Go to JGF (link in my signature below), go to the articles section, and read the NIO articles. That should convince you...

I have read all your articles yesterday, while reading TCP vs UDP thread Smiley They are really extremely helpful, good work. I think I will definitely try to implement it with NIO... and... I will see Smiley

Multiplayer Online Games
http://www.duelboard.com
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Rob Grzywinski

Junior Duke




Reality Interactive


« Reply #3 - Posted 2004-08-20 12:02:42 »

I will confirm Matlu's statement about using Socket.getInputStream's available().  I have used it many times in the past to do "non-blocking" IO with standard IO.  It works very well in a game environment since you have a polling situation (you just check it every pass though the game loop).  It's a serious pain in the butt when you don't (e.g. most enterprise applications).
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (43 views)
2014-10-17 03:59:02

Norakomi (33 views)
2014-10-16 15:22:06

Norakomi (26 views)
2014-10-16 15:20:20

lcass (30 views)
2014-10-15 16:18:58

TehJavaDev (60 views)
2014-10-14 00:39:48

TehJavaDev (60 views)
2014-10-14 00:35:47

TehJavaDev (50 views)
2014-10-14 00:32:37

BurntPizza (66 views)
2014-10-11 23:24:42

BurntPizza (38 views)
2014-10-11 23:10:45

BurntPizza (80 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!