From: SMTP%"rhartman@inet.skillnet.com" 10-JAN-1998 12:21:56.16 To: ntdev@atria.com CC: Subj: [ntdev] Answers to: TransmitFile Questions Return-Path: owner-ntdev@atria.com Received: by arisia.gce.com (UCX V4.1-12C, OpenVMS V7.1 VAX); Sat, 10 Jan 1998 12:20:32 -0500 Received: from gw.atria.com (gw.atria.com [192.88.237.2]) by mercury.mv.net (8.8.8/mem-971025) with SMTP id XAA15133 for ; Fri, 9 Jan 1998 23:00:32 -0500 (EST) Received: by gw.atria.com id Fri, 9 Jan 1998 19:36:29 -0500 Received: from inet.skillnet.com by gw.atria.com id Fri, 9 Jan 1998 19:36:26 -0500 Received: from rlhpc ([207.170.212.66]) by inet.skillnet.com (Post.Office MTA v3.1 release PO203a ID# 0-36931U100L2S100) with SMTP id AAA88 for ; Fri, 9 Jan 1998 16:41:33 -0800 Message-Id: <1.5.4.32.19980109224517.008e5a8c@inet.skillnet.com> X-Sender: rhartman@inet.skillnet.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 09 Jan 1998 14:45:17 -0800 To: ntdev@atria.com From: Richard Hartman Subject: [ntdev] Answers to: TransmitFile Questions Sender: owner-ntdev@atria.com Precedence: bulk X-Majordomo-Taboo: ntdev Some very helpful people within Microsoft have provided answers to the following questions which I posted on this list. Since I believe the list should share answers and not just questions , I've asked for and received permission to post the results. This is not the first time the developers within Microsoft have come through on a specific question, and I wish to thank them publicly for their assistance. It is greatly appreciated. RLH ===== QUESTION: When using TransmitFile (from Win32, not ISAPI) on a socket associated with a completion port, I expect a completion packet to appear when the output operation completes. However, TransmitFile's dwFlags parameter "has three settings", according to the docs. The first two are associated with disconnection (which I don't want) and the last choice is as follows: "TF_WRITE_BEHIND: Complete the TransmitFile request immediately, without pending. If this flag is specified and TransmitFile succeeds, then the data has been accepted by the system but not necessarily acknowledged by the remote end. If TransmitFile returns TRUE, there will be no completion port indication for the I/O. Do not use this setting with the other two settings." It's the second-to-last sentence that's causing me concern. I need a _guaranteed_ completion packet when the output operation completes, just like the behavior of ReadFile and WriteFile on a socket. Is it acceptable to have (dwFlags == NULL)? Does that guarantee a completion packet, even if the call to TransmitFile returns TRUE? This is how ReadFile and WriteFile work - no matter what the function returns, you are guaranteed to get a completion packet. I'm trying to insure that behavior with TransmitFile, but the docs are vague on this. ANSWER: A completion packet will be posted to the completion port associated with a socket for TRUE and (FALSE + ERROR_IO_PENDING) return values. The exception is the use of TF_WRITE_BEHIND, which as the docs say will disable the completion packet. In other words, If TF_WRITE_BEHIND is not used, TransmitFile operates just like ReadFile and WriteFile with respect to completion packets and completion ports. (By the way, this is the way it _should_ work.) ===== QUESTION: Presume a call to TransmitFile where you've specified a head and/or tail in a TRANSMIT_FILE_BUFFERS structure. When the TF completes, does the InternalHigh parameter in the OVERLAPPED structure reflect total bytes transmitted _including_ the head and tail? Or does it only reflect the number of bytes sent from the disk file? If the latter, how can you be certain that the head and tail were successfully transmitted? ANSWER: The InternalHigh parameter will reflect all bytes transmitted on the socket, including the head, file, and tail. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ]