Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  non NIO question  (Read 4862 times)
0 Members and 1 Guest are viewing this topic.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #30 - Posted 2004-01-24 12:21:33 »

Quote

In EITHER case, when you write data out a socket, it first goes into a buffer in the sending computer.  The only time this blocks is if the buffer is full.  Doing anythign else again would make the entire computer potentially stop and wait  on the ether card which you do not want.


Huh Huh

Of *course* you want "the computer to stop and wait on the ethernet card" - that's the main advantage of the concept of synchronous I/O! It's synchronous!

Yes, if you are using Windows 3.1, or some non-multi-threaded OS, this is going to be unacceptable, but this is one of the things threads are so useful for!

This thread contains *several* examples of situations where this is not only the *desired* behaviour, but actually the *required* behaviour in order to achieve particular applications...

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

JGO Coder




Got any cats?


« Reply #31 - Posted 2004-01-25 00:12:42 »

Quote

I've just re-read the TCP RFC 793, where it is "suggested" that OS developers writing a TCP API should offer precisely the information I've described (via an API function called "STATUS"),


Please give the quote.  I woudl like to see if it really says that information on the last sent packet is available immediately after the send call returns, since that is your claim.

AFAIK the JDK APIs represent the Berkeley Unix Socket API, which is the standard on which most other OS's TCP/IP APIs are based.

Until NIO we were missing the select() functionality that Berkeley had, thats why the additions through NIO.


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #32 - Posted 2004-01-25 00:18:35 »

Quote


Huh Huh

Of *course* you want "the computer to stop and wait on the ethernet card" - that's the main advantage of the concept of synchronous I/O! It's synchronous!


To my knowledge, berkeley sockets never were "synchronous" in  that sense.  If you have a man page reference that shwos otherwise I would definitely like to see it.

And the Java java.net. API's don't even claim "sychnronicity" to me knowledge, only that they do certain thinsg in response to the unserlying channels being confugred in certain ways.  I gave those quortes above, if you can find other more apropros quotes from the JDK APi docs please by all means post them.

In terms of "certain applciations require..." since Berkeley sockets don't support such behavior, such applicatiosn are theoretical at best as there was never any way to implement them.

Oh nand speakign of RFCs, I *REALLY* want to see your sources since I went digging last weekand coudl find nothing on the net that describes the behavior you claim.  In fact, whatI did find was all so complex in terms of how TCP/Ip handles failure, retries and time outs that there was no single concrete description I could clip and quote or I would have.

But ANAICT if it worked as you say then all of that wouldn't be necessary.




Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jeff

JGO Coder




Got any cats?


« Reply #33 - Posted 2004-01-25 00:39:01 »

Part of the problem here is a difference in the interpretation of "socket operation completing."

We can agree that, in blocking mode, a Socket wil lnot return until "the requested socket operation is complete."

The fundemental disagremenet here sems to be whether ona write that means just the app side is complete-- that the data has been transferred to the system for output-- or whether that means the data has been received on the other end.

In practice I am pretty dman sure that all the BSD socket programming I ever did in TCP/Ip did not require sucha hand-shake per packet. We did ALL our game networking at TEN in TCP/IP and I KNOW game loops did not stop when we had a latency spike.  

But I am looking for an authortative definiton.  If you can find one that says otherwise I'd love to see it.


Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #34 - Posted 2004-01-25 00:48:38 »

Since you wanted an RFC reference, this seems pretty clear and authoritative:

==================================

RFC1180, Page 24

TCP is a sliding window protocol with time-out and retransmits.
  Outgoing data must be acknowledged by the far-end TCP.
  Acknowledgements can be piggybacked on data.  Both receiving ends can
  flow control the far end, thus preventing a buffer overrun.

  As with all sliding window protocols, the protocol has a window size.
  The window size determines the amount of data that can be transmitted
  before an acknowledgement is required.  For TCP, this amount is not a
  number of TCP segments but a number of bytes.

=====================================

SO it seems very clear to me that acknowledgement of individual writes is NOT requried by the protocol.  The guarantee is that after a certain number of bytes, those bytes must be acknowledged, with that number fo bytes set by a transmission window.

Are we done yet?



Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #35 - Posted 2004-01-25 21:32:28 »

Quote

Please give the quote.  I woudl like to see if it really says that information on the last sent packet is available immediately after the send call returns, since that is your claim.


Sorry, I've confused the issue. I was only saying that I had previously believed that to be the case for *JAVA* in particular, but...

...I then made the point that the TCP spec contains a suggested set of information that should be exposed by an API, but which Java does *NOT* expose; without this info, it is not possible to do things which IMHO you really ought to be able to do in TCP [c.f. below], because it was designed with such use in mind, as far as I had been aware (but I'll need to re-read RFC's etc to check the extent to which these application designs were intended...).

I was then suggesting that, having worked with the TCP RFC before, I'd probably assumed java behaved the way I had because this was the ONLY way that java could fully support all TCP-based application designs, since it doesn't have a "STATUS" command. If you search the 793 for "STATUS" you should find the paras outlining the suggested info. About 3 pages earlier it is at pains to explain that it is NOT mandating this.

The TCP spec suggested info includes "bytes acknowledged". With this information, the API-user can accurately and definitely discover whether or not all their SENT packets have been RECEIVED (...which is the core functionality demanded by the use-cases cited previously; I had naively assumed old-IO in java provided this functionality automatically, since it's API's are dumbed-down, compared to what the RFC suggests. Whilst I've been accepting this is wrong, I've been struggling to accept that it's impossible to achieve in java. If everything you've said is true, it is indeed impossible, which IMHO is limiting enough that it MUST be documented in the API docs).

Quote
Since you wanted an RFC reference, this seems pretty clear and authoritative:

==================================

RFC1180, Page 24

TCP is a sliding window protocol with time-out and retransmits.
  Outgoing data must be acknowledged by the far-end TCP.
  Acknowledgements can be piggybacked on data.  Both receiving ends can
  flow control the far end, thus preventing a buffer overrun.

  As with all sliding window protocols, the protocol has a window size.
  The window size determines the amount of data that can be transmitted
  before an acknowledgement is required.  For TCP, this amount is not a
  number of TCP segments but a number of bytes.

=====================================

SO it seems very clear to me that acknowledgement of individual writes is NOT requried by the protocol.  The guarantee is that after a certain number of bytes, those bytes must be acknowledged, with that number fo bytes set by a transmission window.


You are correct that "acknowledgement of individual writes is NOT required", but that does not mean that the protocol is NOT AWARE of how many bytes have been acknowledged (which is the functionality I've been referring to throughout, albeit perhaps badly explained on my part).

The text you've quoted refers to the "transmission-in-progress" pseudo-state (i.e. my ease-of-explanation definition meaning "what happens in the middle of a transfer" Smiley). My core concern is that once I've *finished* transmitting a set of bytes, I want to know when/whether they've been *successfully* transmitted.

The question is, should I be allowed to know this *only* when I close the TCP connection? The evidence you've offered for java (and for Berkeley, since I'm taking your word for it there) explicitly says I have to close the connection to know that my data was sent.

That sucks.

TCP is a very old protocol, so it's easy to imagine that it was designed for something as low performance as opening and closing a separate stream for each application-level chunk of data (i.e. no pipelining); pipelining made a relatively late move into various RFC's (e.g. HTTP). I'd always worked on the assumption that TCP supports pipelining; the RFC I quoted explicitly "suggests" that implementors "could" provide a set of info that happens to include everything necessary for API-users to implement correct pipelinining with minimal effort, by reusing data that TCP is already keeping track of.

Quote

Are we done yet?


As if! Grin No, seriously, I really want to explain this to you sufficiently that you understand my perspective here. If you think this is better done by email or phone...? Basically, I want you to understand why what I'm suggesting is reasonable to assume, and reasonable to expect. It's sufficiently unlikely that java's old IO sucks THIS much that I basically want an informed second opinion. I'm actually secretly hoping that there's some other way of achieving this "reasonable" functionality in java, and that I just haven't spotted it yet.

Unfortunately, there's only one person I know who knows *everything* I do about networking in java, and a lot more on top, and he's hard to get hold of Sad.

I have some niggling memories in the back of my head of rants by academics against the IO models of Java pre-NIO, and I'm wondering now if we've come across what they were referring to (I didn't pay much attention at the time; I wasn't that interested in networking back then). My vague memory is of hearing them as part of various papers/articles/lectures/pages (can't remember which Sad) outlining "serious fundamental problems" with java; I think it's the same place I first discovered some of the major (but extremely subtle) JVM bugs where e.g. Sun's 1.1.x reference JVM didn't adhere to the JLS in "10 different ways". But it was sooooo long ago... Sad

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

JGO Coder




Got any cats?


« Reply #36 - Posted 2004-01-26 01:27:07 »

I am missing your point, maybe there is something Im stil lnot grapsing.

The quote makes it clear that, for instance, if I send a single byte, an acknowledgement is NOT requried by the protocol

Therefor, by the protocol, no, you CANNOT know that that byte has been received until the handshake for connection closing OR until you send enough additional data to fil lthe window and require an ACK.

Now there are ALSo time-outs in the protocol. My guess is that after a set amoutn of time, if no new data arrives, then it probably ACKs anyway.  Thsoe time-outs and the window itself may even be negotiable and settable under Unix  by ioctls.  

But by default acknowledgement of that single byte write certainly is not immediate on doing the write , nor is that acknowledgement requried in order to write again.






Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Pages: 1 [2]
  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.

CogWheelz (18 views)
2014-07-30 21:08:39

Riven (24 views)
2014-07-29 18:09:19

Riven (15 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (33 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (43 views)
2014-07-24 01:59:36

Riven (43 views)
2014-07-23 21:16:32

Riven (30 views)
2014-07-23 21:07:15

Riven (31 views)
2014-07-23 20:56:16
List of Learning Resources
by SilverTiger
2014-07-31 18:29:50

List of Learning Resources
by SilverTiger
2014-07-31 18:26:06

List of Learning Resources
by SilverTiger
2014-07-31 13:54:12

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54
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!