This has been discussed in the archive and the usual solution is to merge
TDI send together, make a big TDI send request. That improves the
throughput. But I have another scenario, I have made one TDI send request
and the completion routine is not called, then I have made another TDI send
requests. The successive TDI send requests are serialized so that data
packets go in order, but since the previous completion routine is not called
yet then is it possible that the order of request may not not be maintained
by the TDI layer? Could you shed some light on this matter? [FYI: I’m not
using TDI_SEND_NON_BLOCKING, the InFlags value is 0 for TdiBuildSend.]
For TCP, TDI_SEND is completed only when all ACKs will arrive for the
portion. Take care of this and account for this in your design.
TCP does no data buffering or copying, and so it does not implement
SO_SNDBUF.
SO_SNDBUF must be implemented in the TDI client.
So, for small sends, allocate the secondary buffer, copy the data there,
and submit the secondary buffer to TCP. Complete the “master” send just after,
without waiting for TDI_SEND to complete. TDI_SEND completion will only free
the secondary buffer.
----- Original Message -----
From: “Hakim” Newsgroups: ntdev To: “Windows System Software Devs Interest List” Sent: Tuesday, August 31, 2004 8:40 PM Subject: [ntdev] successive TDI send requests
> Hello, > > This has been discussed in the archive and the usual solution is to merge > TDI send together, make a big TDI send request. That improves the > throughput. But I have another scenario, I have made one TDI send request > and the completion routine is not called, then I have made another TDI send > requests. The successive TDI send requests are serialized so that data > packets go in order, but since the previous completion routine is not called > yet then is it possible that the order of request may not not be maintained > by the TDI layer? Could you shed some light on this matter? [FYI: I’m not > using TDI_SEND_NON_BLOCKING, the InFlags value is 0 for TdiBuildSend.] > > Thanks, > Hakim > > > > — > Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com > To unsubscribe send a blank email to xxxxx@lists.osr.com
So, for small sends, allocate the secondary buffer, copy the data there,
and submit the secondary buffer to TCP. Complete the “master” send just
after,
without waiting for TDI_SEND to complete. TDI_SEND completion will only
free
the secondary buffer.
I’m doing exactly this:
Driver gets a write IRP
Copy the data buffer to secondary buffer for TDI send
Complete the IRP, make TDI send request
Process the next IRP and do as step 2 & 3, do not wait for completion
routine of previos TDI send request to be called, since that happen after
getting ACK which I want to avoid actually.
So, I can assume that if TDI sends are timely ordered then data will also go
out in the same order, completion routine will not play any role here. Am I
correct?
“Maxim S. Shatskih” wrote in message news:xxxxx@ntdev… > For TCP, TDI_SEND is completed only when all ACKs will arrive for the > portion. Take care of this and account for this in your design. > > TCP does no data buffering or copying, and so it does not implement > SO_SNDBUF. > SO_SNDBUF must be implemented in the TDI client. > > So, for small sends, allocate the secondary buffer, copy the data there, > and submit the secondary buffer to TCP. Complete the “master” send just after, > without waiting for TDI_SEND to complete. TDI_SEND completion will only free > the secondary buffer. > > Maxim Shatskih, Windows DDK MVP > StorageCraft Corporation > xxxxx@storagecraft.com > http://www.storagecraft.com > > ----- Original Message ----- > From: “Hakim” > Newsgroups: ntdev > To: “Windows System Software Devs Interest List” > Sent: Tuesday, August 31, 2004 8:40 PM > Subject: [ntdev] successive TDI send requests > > > > Hello, > > > > This has been discussed in the archive and the usual solution is to merge > > TDI send together, make a big TDI send request. That improves the > > throughput. But I have another scenario, I have made one TDI send request > > and the completion routine is not called, then I have made another TDI send > > requests. The successive TDI send requests are serialized so that data > > packets go in order, but since the previous completion routine is not called > > yet then is it possible that the order of request may not not be maintained > > by the TDI layer? Could you shed some light on this matter? [FYI: I’m not > > using TDI_SEND_NON_BLOCKING, the InFlags value is 0 for TdiBuildSend.] > > > > Thanks, > > Hakim > > > > > > > > — > > Questions? First check the Kernel Driver FAQ at > http://www.osronline.com/article.cfm?id=256 > > > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com > > To unsubscribe send a blank email to xxxxx@lists.osr.com > >
> So, I can assume that if TDI sends are timely ordered then data will also go
out in the same order, completion routine will not play any role here. Am I
correct?
Correct. Just do not send too many unACKed data to TCP.
Maintain the counter of “bytes inside pending TDI_SENDs”, and, if it hits some
limit, send directly without the additional buffer, and wait for TDI_SEND to
complete.
My intention is to send maximum three unACKed send or the size limit is
3*1460 (a Send request of 1460*3 will produce three sends from TDI layer)
whichever hits first. By going through RFC about delay ACK algorithm it
seems that if I make three send requests in a row then the first send will
get ACK rightway after the third request received by the remote end
dismissing the delay ACK timer. Is this the right approach?
Thanks,
Hakim
“Maxim S. Shatskih” wrote in message news:xxxxx@ntdev… > > So, I can assume that if TDI sends are timely ordered then data will also go > > out in the same order, completion routine will not play any role here. Am I > > correct? > > Correct. Just do not send too many unACKed data to TCP. > > Maintain the counter of “bytes inside pending TDI_SENDs”, and, if it hits some > limit, send directly without the additional buffer, and wait for TDI_SEND to > complete. > > This limit is your SO_SNDBUF. > > Maxim Shatskih, Windows DDK MVP > StorageCraft Corporation > xxxxx@storagecraft.com > http://www.storagecraft.com > >
The goal is to send as much as possible using a single RTT, at least for a
bulk traffic (for transcation processing, 1 transaction per RTT is a
theoretical limit).
To maintain this goal, you should feed the pipeline full enough so that it
will not be drained at the moment of opening the sender window. Such a drain
means idle time in the connection, the time when it was OK to send data, and
this was not done due to sender stupidity. This decreases the sender throughput
a lot.
This is why we have SO_SNDBUF, which is around 64 or even 256KB.
----- Original Message -----
From: “Hakim” Newsgroups: ntdev To: “Windows System Software Devs Interest List” Sent: Tuesday, August 31, 2004 9:43 PM Subject: Re:[ntdev] Re:successive TDI send requests
> > Just do not send too many unACKed data to TCP. > > My intention is to send maximum three unACKed send or the size limit is > 31460 (a Send request of 14603 will produce three sends from TDI layer) > whichever hits first. By going through RFC about delay ACK algorithm it > seems that if I make three send requests in a row then the first send will > get ACK rightway after the third request received by the remote end > dismissing the delay ACK timer. Is this the right approach? > > Thanks, > Hakim > > “Maxim S. Shatskih” wrote in message > news:xxxxx@ntdev… > > > So, I can assume that if TDI sends are timely ordered then data will > also go > > > out in the same order, completion routine will not play any role here. > Am I > > > correct? > > > > Correct. Just do not send too many unACKed data to TCP. > > > > Maintain the counter of “bytes inside pending TDI_SENDs”, and, if it hits > some > > limit, send directly without the additional buffer, and wait for TDI_SEND > to > > complete. > > > > This limit is your SO_SNDBUF. > > > > Maxim Shatskih, Windows DDK MVP > > StorageCraft Corporation > > xxxxx@storagecraft.com > > http://www.storagecraft.com > > > > > > > > — > Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com > To unsubscribe send a blank email to xxxxx@lists.osr.com
Thanks for the suggestion, I’ll change the design accordingly. There is a
small challenge I’m facing is to get SO_SNDBUF by
IOCTL_TCP_QUERY_INFORMATION_EX using TDI interface. I’m having touble to get
this value. Here is my struct value for TCP_REQUEST_QUERY_INFORMATION_EX
What will be the value for SO_SNDBUF? It seems to be 0x1001 from looking at
some header but the IOCTL fails meaning parameters in the
TCP_REQUEST_QUERY_INFORMATION_EX are wrong or it may need digging through
multiple structs as it is done to get IP address. Could you give me some
hints in this dark area?
Hakim
“Maxim S. Shatskih” wrote in message news:xxxxx@ntdev… > The goal is to send as much as possible using a single RTT, at least for a > bulk traffic (for transcation processing, 1 transaction per RTT is a > theoretical limit). > > To maintain this goal, you should feed the pipeline full enough so that it > will not be drained at the moment of opening the sender window. Such a drain > means idle time in the connection, the time when it was OK to send data, and > this was not done due to sender stupidity. This decreases the sender throughput > a lot. > > This is why we have SO_SNDBUF, which is around 64 or even 256KB. > > Maxim Shatskih, Windows DDK MVP > StorageCraft Corporation > xxxxx@storagecraft.com > http://www.storagecraft.com > > ----- Original Message ----- > From: “Hakim” > Newsgroups: ntdev > To: “Windows System Software Devs Interest List” > Sent: Tuesday, August 31, 2004 9:43 PM > Subject: Re:[ntdev] Re:successive TDI send requests > > > > > Just do not send too many unACKed data to TCP. > > > > My intention is to send maximum three unACKed send or the size limit is > > 31460 (a Send request of 14603 will produce three sends from TDI layer) > > whichever hits first. By going through RFC about delay ACK algorithm it > > seems that if I make three send requests in a row then the first send will > > get ACK rightway after the third request received by the remote end > > dismissing the delay ACK timer. Is this the right approach? > > > > Thanks, > > Hakim > > > > “Maxim S. Shatskih” wrote in message > > news:xxxxx@ntdev… > > > > So, I can assume that if TDI sends are timely ordered then data will > > also go > > > > out in the same order, completion routine will not play any role here. > > Am I > > > > correct? > > > > > > Correct. Just do not send too many unACKed data to TCP. > > > > > > Maintain the counter of “bytes inside pending TDI_SENDs”, and, if it hits > > some > > > limit, send directly without the additional buffer, and wait for TDI_SEND > > to > > > complete. > > > > > > This limit is your SO_SNDBUF. > > > > > > Maxim Shatskih, Windows DDK MVP > > > StorageCraft Corporation > > > xxxxx@storagecraft.com > > > http://www.storagecraft.com > > > > > > > > > > > > > > — > > Questions? First check the Kernel Driver FAQ at > http://www.osronline.com/article.cfm?id=256 > > > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com > > To unsubscribe send a blank email to xxxxx@lists.osr.com > >
----- Original Message -----
From: “Hakim” Newsgroups: ntdev To: “Windows System Software Devs Interest List” Sent: Thursday, September 02, 2004 5:44 PM Subject: Re:[ntdev] Re:Re:successive TDI send requests
> Thanks for the suggestion, I’ll change the design accordingly. There is a > small challenge I’m facing is to get SO_SNDBUF by > IOCTL_TCP_QUERY_INFORMATION_EX using TDI interface. I’m having touble to get > this value. Here is my struct value for TCP_REQUEST_QUERY_INFORMATION_EX > > ID.toi_entity.tei_entity = CO_TL_ENTITY; > ID.toi_entity.tei_instance = TL_INSTANCE; > ID.toi_class = INFO_CLASS_PROTOCOL > ID.toi_type = INFO_TYPE_CONNECTION > ID.toi_id = SO_SNDBUF > > What will be the value for SO_SNDBUF? It seems to be 0x1001 from looking at > some header but the IOCTL fails meaning parameters in the > TCP_REQUEST_QUERY_INFORMATION_EX are wrong or it may need digging through > multiple structs as it is done to get IP address. Could you give me some > hints in this dark area? > > Hakim > > “Maxim S. Shatskih” wrote in message > news:xxxxx@ntdev… > > The goal is to send as much as possible using a single RTT, at least > for a > > bulk traffic (for transcation processing, 1 transaction per RTT is a > > theoretical limit). > > > > To maintain this goal, you should feed the pipeline full enough so > that it > > will not be drained at the moment of opening the sender window. Such a > drain > > means idle time in the connection, the time when it was OK to send data, > and > > this was not done due to sender stupidity. This decreases the sender > throughput > > a lot. > > > > This is why we have SO_SNDBUF, which is around 64 or even 256KB. > > > > Maxim Shatskih, Windows DDK MVP > > StorageCraft Corporation > > xxxxx@storagecraft.com > > http://www.storagecraft.com > > > > ----- Original Message ----- > > From: “Hakim” > > Newsgroups: ntdev > > To: “Windows System Software Devs Interest List” > > Sent: Tuesday, August 31, 2004 9:43 PM > > Subject: Re:[ntdev] Re:successive TDI send requests > > > > > > > > Just do not send too many unACKed data to TCP. > > > > > > My intention is to send maximum three unACKed send or the size limit is > > > 31460 (a Send request of 14603 will produce three sends from TDI > layer) > > > whichever hits first. By going through RFC about delay ACK algorithm it > > > seems that if I make three send requests in a row then the first send > will > > > get ACK rightway after the third request received by the remote end > > > dismissing the delay ACK timer. Is this the right approach? > > > > > > Thanks, > > > Hakim > > > > > > “Maxim S. Shatskih” wrote in message > > > news:xxxxx@ntdev… > > > > > So, I can assume that if TDI sends are timely ordered then data will > > > also go > > > > > out in the same order, completion routine will not play any role > here. > > > Am I > > > > > correct? > > > > > > > > Correct. Just do not send too many unACKed data to TCP. > > > > > > > > Maintain the counter of “bytes inside pending TDI_SENDs”, and, if it > hits > > > some > > > > limit, send directly without the additional buffer, and wait for > TDI_SEND > > > to > > > > complete. > > > > > > > > This limit is your SO_SNDBUF. > > > > > > > > Maxim Shatskih, Windows DDK MVP > > > > StorageCraft Corporation > > > > xxxxx@storagecraft.com > > > > http://www.storagecraft.com > > > > > > > > > > > > > > > > > > > > — > > > Questions? First check the Kernel Driver FAQ at > > http://www.osronline.com/article.cfm?id=256 > > > > > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com > > > To unsubscribe send a blank email to xxxxx@lists.osr.com > > > > > > > > — > Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com > To unsubscribe send a blank email to xxxxx@lists.osr.com
You mean I can only set SO_SNDBUF for my client using
IOCTL_TCP_SET_INFORMATION_EX?
If so what would be the way to setup, any hints on ID.toi_id?
Or, could you give me some knowledgebase reference for its implementation?
Thanks,
Hakim
“Maxim S. Shatskih” wrote in message news:xxxxx@ntdev… > You cannot. SO_SNDBUF is not implemented in TCP. > > It must be impemented in all TDI clients. For instance, AFD implements it. > > Maxim Shatskih, Windows DDK MVP > StorageCraft Corporation > xxxxx@storagecraft.com > http://www.storagecraft.com > > ----- Original Message ----- > From: “Hakim” > Newsgroups: ntdev > To: “Windows System Software Devs Interest List” > Sent: Thursday, September 02, 2004 5:44 PM > Subject: Re:[ntdev] Re:Re:successive TDI send requests > > > > Thanks for the suggestion, I’ll change the design accordingly. There is a > > small challenge I’m facing is to get SO_SNDBUF by > > IOCTL_TCP_QUERY_INFORMATION_EX using TDI interface. I’m having touble to get > > this value. Here is my struct value for TCP_REQUEST_QUERY_INFORMATION_EX > > > > ID.toi_entity.tei_entity = CO_TL_ENTITY; > > ID.toi_entity.tei_instance = TL_INSTANCE; > > ID.toi_class = INFO_CLASS_PROTOCOL > > ID.toi_type = INFO_TYPE_CONNECTION > > ID.toi_id = SO_SNDBUF > > > > What will be the value for SO_SNDBUF? It seems to be 0x1001 from looking at > > some header but the IOCTL fails meaning parameters in the > > TCP_REQUEST_QUERY_INFORMATION_EX are wrong or it may need digging through > > multiple structs as it is done to get IP address. Could you give me some > > hints in this dark area? > > > > Hakim > > > > “Maxim S. Shatskih” wrote in message > > news:xxxxx@ntdev… > > > The goal is to send as much as possible using a single RTT, at least > > for a > > > bulk traffic (for transcation processing, 1 transaction per RTT is a > > > theoretical limit). > > > > > > To maintain this goal, you should feed the pipeline full enough so > > that it > > > will not be drained at the moment of opening the sender window. Such a > > drain > > > means idle time in the connection, the time when it was OK to send data, > > and > > > this was not done due to sender stupidity. This decreases the sender > > throughput > > > a lot. > > > > > > This is why we have SO_SNDBUF, which is around 64 or even 256KB. > > > > > > Maxim Shatskih, Windows DDK MVP > > > StorageCraft Corporation > > > xxxxx@storagecraft.com > > > http://www.storagecraft.com > > > > > > ----- Original Message ----- > > > From: “Hakim” > > > Newsgroups: ntdev > > > To: “Windows System Software Devs Interest List” > > > Sent: Tuesday, August 31, 2004 9:43 PM > > > Subject: Re:[ntdev] Re:successive TDI send requests > > > > > > > > > > > Just do not send too many unACKed data to TCP. > > > > > > > > My intention is to send maximum three unACKed send or the size limit is > > > > 31460 (a Send request of 14603 will produce three sends from TDI > > layer) > > > > whichever hits first. By going through RFC about delay ACK algorithm it > > > > seems that if I make three send requests in a row then the first send > > will > > > > get ACK rightway after the third request received by the remote end > > > > dismissing the delay ACK timer. Is this the right approach? > > > > > > > > Thanks, > > > > Hakim > > > > > > > > “Maxim S. Shatskih” wrote in message > > > > news:xxxxx@ntdev… > > > > > > So, I can assume that if TDI sends are timely ordered then data will > > > > also go > > > > > > out in the same order, completion routine will not play any role > > here. > > > > Am I > > > > > > correct? > > > > > > > > > > Correct. Just do not send too many unACKed data to TCP. > > > > > > > > > > Maintain the counter of “bytes inside pending TDI_SENDs”, and, if it > > hits > > > > some > > > > > limit, send directly without the additional buffer, and wait for > > TDI_SEND > > > > to > > > > > complete. > > > > > > > > > > This limit is your SO_SNDBUF. > > > > > > > > > > Maxim Shatskih, Windows DDK MVP > > > > > StorageCraft Corporation > > > > > xxxxx@storagecraft.com > > > > > http://www.storagecraft.com > > > > > > > > > > > > > > > > > > > > > > > > > > — > > > > Questions? First check the Kernel Driver FAQ at > > > http://www.osronline.com/article.cfm?id=256 > > > > > > > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com > > > > To unsubscribe send a blank email to xxxxx@lists.osr.com > > > > > > > > > > > > > > — > > Questions? First check the Kernel Driver FAQ at > http://www.osronline.com/article.cfm?id=256 > > > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com > > To unsubscribe send a blank email to xxxxx@lists.osr.com > >
----- Original Message -----
From: “Hakim” Newsgroups: ntdev To: “Windows System Software Devs Interest List” Sent: Thursday, September 02, 2004 7:41 PM Subject: Re:[ntdev] Re:Re:Re:successive TDI send requests
> You mean I can only set SO_SNDBUF for my client using > IOCTL_TCP_SET_INFORMATION_EX? > If so what would be the way to setup, any hints on ID.toi_id? > > Or, could you give me some knowledgebase reference for its implementation? > > Thanks, > Hakim > > “Maxim S. Shatskih” wrote in message > news:xxxxx@ntdev… > > You cannot. SO_SNDBUF is not implemented in TCP. > > > > It must be impemented in all TDI clients. For instance, AFD implements > it. > > > > Maxim Shatskih, Windows DDK MVP > > StorageCraft Corporation > > xxxxx@storagecraft.com > > http://www.storagecraft.com > > > > ----- Original Message ----- > > From: “Hakim” > > Newsgroups: ntdev > > To: “Windows System Software Devs Interest List” > > Sent: Thursday, September 02, 2004 5:44 PM > > Subject: Re:[ntdev] Re:Re:successive TDI send requests > > > > > > > Thanks for the suggestion, I’ll change the design accordingly. There is > a > > > small challenge I’m facing is to get SO_SNDBUF by > > > IOCTL_TCP_QUERY_INFORMATION_EX using TDI interface. I’m having touble to > get > > > this value. Here is my struct value for TCP_REQUEST_QUERY_INFORMATION_EX > > > > > > ID.toi_entity.tei_entity = CO_TL_ENTITY; > > > ID.toi_entity.tei_instance = TL_INSTANCE; > > > ID.toi_class = INFO_CLASS_PROTOCOL > > > ID.toi_type = INFO_TYPE_CONNECTION > > > ID.toi_id = SO_SNDBUF > > > > > > What will be the value for SO_SNDBUF? It seems to be 0x1001 from looking > at > > > some header but the IOCTL fails meaning parameters in the > > > TCP_REQUEST_QUERY_INFORMATION_EX are wrong or it may need digging > through > > > multiple structs as it is done to get IP address. Could you give me some > > > hints in this dark area? > > > > > > Hakim > > > > > > “Maxim S. Shatskih” wrote in message > > > news:xxxxx@ntdev… > > > > The goal is to send as much as possible using a single RTT, at > least > > > for a > > > > bulk traffic (for transcation processing, 1 transaction per RTT is a > > > > theoretical limit). > > > > > > > > To maintain this goal, you should feed the pipeline full enough so > > > that it > > > > will not be drained at the moment of opening the sender window. Such a > > > drain > > > > means idle time in the connection, the time when it was OK to send > data, > > > and > > > > this was not done due to sender stupidity. This decreases the sender > > > throughput > > > > a lot. > > > > > > > > This is why we have SO_SNDBUF, which is around 64 or even 256KB. > > > > > > > > Maxim Shatskih, Windows DDK MVP > > > > StorageCraft Corporation > > > > xxxxx@storagecraft.com > > > > http://www.storagecraft.com > > > > > > > > ----- Original Message ----- > > > > From: “Hakim” > > > > Newsgroups: ntdev > > > > To: “Windows System Software Devs Interest List” > > > > Sent: Tuesday, August 31, 2004 9:43 PM > > > > Subject: Re:[ntdev] Re:successive TDI send requests > > > > > > > > > > > > > > Just do not send too many unACKed data to TCP. > > > > > > > > > > My intention is to send maximum three unACKed send or the size limit > is > > > > > 31460 (a Send request of 14603 will produce three sends from TDI > > > layer) > > > > > whichever hits first. By going through RFC about delay ACK algorithm > it > > > > > seems that if I make three send requests in a row then the first > send > > > will > > > > > get ACK rightway after the third request received by the remote end > > > > > dismissing the delay ACK timer. Is this the right approach? > > > > > > > > > > Thanks, > > > > > Hakim > > > > > > > > > > “Maxim S. Shatskih” wrote in message > > > > > news:xxxxx@ntdev… > > > > > > > So, I can assume that if TDI sends are timely ordered then data > will > > > > > also go > > > > > > > out in the same order, completion routine will not play any role > > > here. > > > > > Am I > > > > > > > correct? > > > > > > > > > > > > Correct. Just do not send too many unACKed data to TCP. > > > > > > > > > > > > Maintain the counter of “bytes inside pending TDI_SENDs”, and, if > it > > > hits > > > > > some > > > > > > limit, send directly without the additional buffer, and wait for > > > TDI_SEND > > > > > to > > > > > > complete. > > > > > > > > > > > > This limit is your SO_SNDBUF. > > > > > > > > > > > > Maxim Shatskih, Windows DDK MVP > > > > > > StorageCraft Corporation > > > > > > xxxxx@storagecraft.com > > > > > > http://www.storagecraft.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > — > > > > > Questions? First check the Kernel Driver FAQ at > > > > http://www.osronline.com/article.cfm?id=256 > > > > > > > > > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com > > > > > To unsubscribe send a blank email to > xxxxx@lists.osr.com > > > > > > > > > > > > > > > > > > > > — > > > Questions? First check the Kernel Driver FAQ at > > http://www.osronline.com/article.cfm?id=256 > > > > > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com > > > To unsubscribe send a blank email to xxxxx@lists.osr.com > > > > > > > > — > Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com > To unsubscribe send a blank email to xxxxx@lists.osr.com
The only sample I find in the DDK is wshsmple. I didn’t find any
implementation info on AFD in DDK but there are scattered references on AFD
in DDK help. Is there any info on AFD around or I have to collect by
searching though DDK help and summarise?
Thanks,
Hakim
“Maxim S. Shatskih” wrote in message news:xxxxx@ntdev… > I responded on this subject a bit ago. > > Maxim Shatskih, Windows DDK MVP > StorageCraft Corporation > xxxxx@storagecraft.com > http://www.storagecraft.com > > ----- Original Message ----- > From: “Hakim” > Newsgroups: ntdev > To: “Windows System Software Devs Interest List” > Sent: Thursday, September 02, 2004 7:41 PM > Subject: Re:[ntdev] Re:Re:Re:successive TDI send requests > > > > You mean I can only set SO_SNDBUF for my client using > > IOCTL_TCP_SET_INFORMATION_EX? > > If so what would be the way to setup, any hints on ID.toi_id? > > > > Or, could you give me some knowledgebase reference for its implementation? > > > > Thanks, > > Hakim > > > > “Maxim S. Shatskih” wrote in message > > news:xxxxx@ntdev… > > > You cannot. SO_SNDBUF is not implemented in TCP. > > > > > > It must be impemented in all TDI clients. For instance, AFD implements > > it. > > > > > > Maxim Shatskih, Windows DDK MVP > > > StorageCraft Corporation > > > xxxxx@storagecraft.com > > > http://www.storagecraft.com > > > > > > ----- Original Message ----- > > > From: “Hakim” > > > Newsgroups: ntdev > > > To: “Windows System Software Devs Interest List” > > > Sent: Thursday, September 02, 2004 5:44 PM > > > Subject: Re:[ntdev] Re:Re:successive TDI send requests > > > > > > > > > > Thanks for the suggestion, I’ll change the design accordingly. There is > > a > > > > small challenge I’m facing is to get SO_SNDBUF by > > > > IOCTL_TCP_QUERY_INFORMATION_EX using TDI interface. I’m having touble to > > get > > > > this value. Here is my struct value for TCP_REQUEST_QUERY_INFORMATION_EX > > > > > > > > ID.toi_entity.tei_entity = CO_TL_ENTITY; > > > > ID.toi_entity.tei_instance = TL_INSTANCE; > > > > ID.toi_class = INFO_CLASS_PROTOCOL > > > > ID.toi_type = INFO_TYPE_CONNECTION > > > > ID.toi_id = SO_SNDBUF > > > > > > > > What will be the value for SO_SNDBUF? It seems to be 0x1001 from looking > > at > > > > some header but the IOCTL fails meaning parameters in the > > > > TCP_REQUEST_QUERY_INFORMATION_EX are wrong or it may need digging > > through > > > > multiple structs as it is done to get IP address. Could you give me some > > > > hints in this dark area? > > > > > > > > Hakim > > > > > > > > “Maxim S. Shatskih” wrote in message > > > > news:xxxxx@ntdev… > > > > > The goal is to send as much as possible using a single RTT, at > > least > > > > for a > > > > > bulk traffic (for transcation processing, 1 transaction per RTT is a > > > > > theoretical limit). > > > > > > > > > > To maintain this goal, you should feed the pipeline full enough so > > > > that it > > > > > will not be drained at the moment of opening the sender window. Such a > > > > drain > > > > > means idle time in the connection, the time when it was OK to send > > data, > > > > and > > > > > this was not done due to sender stupidity. This decreases the sender > > > > throughput > > > > > a lot. > > > > > > > > > > This is why we have SO_SNDBUF, which is around 64 or even 256KB. > > > > > > > > > > Maxim Shatskih, Windows DDK MVP > > > > > StorageCraft Corporation > > > > > xxxxx@storagecraft.com > > > > > http://www.storagecraft.com > > > > > > > > > > ----- Original Message ----- > > > > > From: “Hakim” > > > > > Newsgroups: ntdev > > > > > To: “Windows System Software Devs Interest List”
> > > > > Sent: Tuesday, August 31, 2004 9:43 PM > > > > > Subject: Re:[ntdev] Re:successive TDI send requests > > > > > > > > > > > > > > > > > Just do not send too many unACKed data to TCP. > > > > > > > > > > > > My intention is to send maximum three unACKed send or the size limit > > is > > > > > > 31460 (a Send request of 14603 will produce three sends from TDI > > > > layer) > > > > > > whichever hits first. By going through RFC about delay ACK algorithm > > it > > > > > > seems that if I make three send requests in a row then the first > > send > > > > will > > > > > > get ACK rightway after the third request received by the remote end > > > > > > dismissing the delay ACK timer. Is this the right approach? > > > > > > > > > > > > Thanks, > > > > > > Hakim > > > > > > > > > > > > “Maxim S. Shatskih” wrote in message > > > > > > news:xxxxx@ntdev… > > > > > > > > So, I can assume that if TDI sends are timely ordered then data > > will > > > > > > also go > > > > > > > > out in the same order, completion routine will not play any role > > > > here. > > > > > > Am I > > > > > > > > correct? > > > > > > > > > > > > > > Correct. Just do not send too many unACKed data to TCP. > > > > > > > > > > > > > > Maintain the counter of “bytes inside pending TDI_SENDs”, and, if > > it > > > > hits > > > > > > some > > > > > > > limit, send directly without the additional buffer, and wait for > > > > TDI_SEND > > > > > > to > > > > > > > complete. > > > > > > > > > > > > > > This limit is your SO_SNDBUF. > > > > > > > > > > > > > > Maxim Shatskih, Windows DDK MVP > > > > > > > StorageCraft Corporation > > > > > > > xxxxx@storagecraft.com > > > > > > > http://www.storagecraft.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > — > > > > > > Questions? First check the Kernel Driver FAQ at > > > > > http://www.osronline.com/article.cfm?id=256 > > > > > > > > > > > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com > > > > > > To unsubscribe send a blank email to > > xxxxx@lists.osr.com > > > > > > > > > > > > > > > > > > > > > > > > > > — > > > > Questions? First check the Kernel Driver FAQ at > > > http://www.osronline.com/article.cfm?id=256 > > > > > > > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com > > > > To unsubscribe send a blank email to xxxxx@lists.osr.com > > > > > > > > > > > > > > — > > Questions? First check the Kernel Driver FAQ at > http://www.osronline.com/article.cfm?id=256 > > > > You are currently subscribed to ntdev as: xxxxx@storagecraft.com > > To unsubscribe send a blank email to xxxxx@lists.osr.com > >