And it's not due to the fact that the thread calling the ReadFile function is put to sleep by the OS and ReadFile has had time to read only 4292 bytes when it is put to sleep, NO, it's something else.
Yes it's called networking and therefore....
racette wrote:
But I don't believe my experience with networking has anything to do with the question I asked.
.... that statement is dead wrong. I don't know how to put this any simpler. Networking and threading requires you actually know stuff. You can't just drag and drop some VB controls on a form and get it to work, period.
As I stated earlier, you are lacking understanding of some fundamental issues and unless you gain that understanding you will continue to struggle. I strongly urge you to stop working on your project and do some studying of network programming issues. This would include reading and then writing, executing and observing networking code in research projects. Unless of course someone on your team already has the knowledge and experience you require, if so just get them to work with you.
If indeed your team does not have said experience, it seems that the decision to use named pipes is premature.
I strongly urge you to stop working on your project and do some studying of network programming issues. This would include reading and then writing, executing and observing networking code in research projects.
That's what I'm doing right now. I'm doing tests.
Now, there must be tons of material to read on network programming issues, don't you have a particular one that could be of interest to me?
Benjamin Racette
CAE software developer
racette@cae.com
Networking and threading requires you actually know stuff. You can't just drag and drop some VB controls on a form and get it to work, period.
Well, I do know a lot about threading and the different synchronisation mechanism in the win32 API. So this part I know. My inexperience relates only to the network part.
led mike wrote:
If indeed your team does not have said experience, it seems that the decision to use named pipes is premature.
Yes I agree with you. I'm an intern here and the decision to use named pipes was made more or less without my agreement. It seemed like everyone here wanted to use them, so I have to work with that even though I never used them.
Thanks.
Benjamin Racette
CAE software developer
racette@cae.com
I strongly urge you to stop working on your project and do some studying of network programming issues. This would include reading and then writing, executing and observing networking code in research projects.
I did some tests and discovered that I don't get the problem of 4292 bytes being sent and received when I switched to PIPE_TYPE_MESSAGE instead of PIPE_TYPE_BYTE. However, I think I went back to synchronous I/O with PIPE_TYPE_MESSAGE since I read somewhere that this type of pipe enables a mode known as 'write-through' (FILE_FLAG_WRITE_THROUGH option).
Can someone confirm this?
Also, is there a way to achieve asynchronous overlapped I/O with PIPE_TYPE_MESSAGE pipes?
Thanks!
Benjamin Racette
CAE software developer
racette@cae.com
However, I think I went back to synchronous I/O with PIPE_TYPE_MESSAGE since I read somewhere that this type of pipe enables a mode known as 'write-through' (FILE_FLAG_WRITE_THROUGH option).
Have you read the documentation for CreateNamedPipe? That statement seems to contradict the documentation.
Have you read the documentation for CreateNamedPipe?
Yes, of course. As I said already, I read all those MSDN pages a lot of times each.
I found the article where it is mentionned that read and write operations on a message-type named pipes are treated as if WRITE_THROUGH mode was enabled.
I found the article where it is mentionned that read and write operations on a message-type named pipes are treated as if WRITE_THROUGH mode was enabled.
The description of the FILE_FLAG_WRITE_THROUGH option goes like this:
Write-through mode is enabled. This mode affects only write operations on byte-type pipes and, then, only when the client and server processes are on different computers.
No matter what the answer is, is it possible to achieve asynchronous I/O with message-type named pipes?
Yes for read operations. For write operations I don't know if will block or not. However what seems more significant is that the efficiency will not occur:
If this mode is not enabled, the system enhances the efficiency of network operations by buffering data until a minimum number of bytes accumulate or until a maximum time elapses.
That information also speaks to the different ways data transmission libraries use buffering that may or may not effect user code that is reading/writing using the libraries which is what you have been seeing.
Now in your early posts you indicated that your team decided to use named pipes for efficiency reasons. Following that decision I would not think the write through option is appropriate for your solution so your concern over overlapped operations in that mode seems inappropriate.
Same principles apply to pipes (which very well may be using sockets underneath).
Like I stated in my other reply to you here, you need to check if all the bytes you request to send and receive
actually get sent and received. If not, then you need to continue sending and receiving until you do.
You are correct of course but Benjamin has some "fundamentals" problems that he needs to get straight before any of that matters. See my last post, it's a common theme (struggling to grasp the concepts) that occurs with an introduction into both subjects, threading and asynchronous operations. Actually for me, anytime I have a gap in time of doing either, I go through the struggle each time I have to do it again.
it's a common theme (struggling to grasp the concepts) that occurs with an introduction into both subjects, threading and asynchronous operations.
Indeed
led mike wrote:
Actually for me, anytime I have a gap in time of doing either, I go through the struggle each time I have to do it again.
Heh it's like that for me with anything. That's probably the biggest reason I respond to questions here - so I can keep
a little sharp on stuff I don't use often. Graphics, asynchronous I/O, and threading, however, I do every day, all day.
I tried something like that but it would not work. I put the ReadFile in a while loop and I changed the offset of the buffer and the number of bytes to read by an amount I got from a call to GetOverlappedResult but it gave me weird results.
I guess led mike is right when he says that there is fundamental things I need to understand before getting things right.
Thanks for your comment and suggestion.
Benjamin Racette
CAE software developer
racette@cae.com
Does a call to GetOverlappedResult() keeps on reading or writing or should I call WriteFile or ReadFile again and again until its done?
You are responsible for checking the overlapped result and sending/receiving any remaining bytes.
FWIW, if you are calling GetOverlappedResult() right after a function call fails with ERROR_IO_PENDING,
then you're essentially doing synchronous I/O, and all you've done is added complexity to the code.
hey, that's nice to answer, but you know, we have dedicated forums, so if a question is asked at the wrong place, we shouldn't answer, because it will encourage others to ask anywhere.
I see you also answered the "Time" Question. Same remark applies there too.
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
