[HECnet] Re: DECnet equivalent of PSH?

This is an interesting thread.  Let me see if I can untangle it enough to glean the understanding I'm looking for.  I believe there is some amount of vagueness on my part which is due to not understanding the correct question to ask nor how to properly phrase the thing.  I think another conceptual problem is that I tend to think API instead of protocol, which can confuse the matter. Again, the vast bulk of my programming experience has been with TCP/IP and those related RFC's, some of which we ported to DECnet (SMTP comes to mind). The question here that I'm converging on is, "when do you return from the API call"?  In TCP/IP, I'm not sure it is as well defined as I would like. A comparison with FTP is somewhat illustrative, although once again, DAP and FTP are vastly different things.  For FTP, the control port is actually running RFC 854 TELNET, so you know you are going to wake up on every line break.  Once negotiated, the data port is a stream of bytes which may or may not have blocking in it.  You wake up early from a read in that case because the sender closes the port at end of file. Paged file structures completely broke this by holding the data port open, so you have no implied end of file, but have to poll for data, which is disgusting.  That's why I know about PSH because I use it to try to guess end of stream.  It's a hack. That being said, I think where I got confused was understanding the difference between the various levels of buffering, blocking and enforcing record structure.  It's straightforward enough, but somewhat hairy in places and in others, perhaps unfortunate.  In a transfer, data is buffered up in a linked list (the send queue) and flushed based on a number of criteria.  One example, is the number of files done.  For large directories, this can cause the memory usage to vastly expand as everything is sent at once.  That had caused memory issues, which edit 111 partially fixed (but is kind of a hack, as I recall). When emptying the send queue, Tops-20 DAP only sets end of record on the last message in the queue, which was confusing.  The receiving DAP appears to have to know that it may get a number of records in one read.  I think what's happening is that Tops-20 DAP is signaling, "I'm done sending you some stuff, I won't send you any more and I'm expecting you to respond" Again, what's happening here is confusing to me, which indicates I ought review the DAP specification again.  I was going to do that, anyway to break out the flag names (instead of just typing the bits)