#Step 7 micro win full or half duplex how to#
#Step 7 micro win full or half duplex code#

Many embedded systems include peripheral devices connected to the microprocessor in order to expand its capabilities. A simple pushbutton and LEDs controller is useful but if that controller cannot report when a user has pressed a button or share the status its LED indicate, the controllers are not worth their value.

Your brain is smarter than any micro-chip.In embedded systems, a simple function rarely exists alone. All I'm asking is that the Pipe Stream react the same. Simply put, the FileStream() object, when used on a file that has nothing in it, and I execute a 'Read' i either get an array of 0's or a EOF exception, and the same happens on a MemoryStream.

Net, I'll be able to give it the parameters and formats I want, and voila, I only need to listen to one event on both client and server and everything is pre-built the way I want it to be. I may tweak it a bit here or there, but for as long as I use. My Class handles all manner of communication between both pipes directly, in a manner that from here until armageddon I don't need to rewrite the class. Sure I could have the PipeStream handle the Asyncrhonous communication, and then trigger an event when a message is received asynchronously, but that convoludes the concept of the event driven PipeStream class i've devised. Net handled Async operations can sometimes screw the pooch because they are threads within threads within threads. SOmetimes there are other things that need to be going on in those other threads, and as my other posts have indicated, those. It may confuse some of the people on this forum, but sometimes I want to manage the asynchronous operations, instead of allowing. The Concept of the Begin* End* methods is to handle Asyncrhonous operations on everything, wether it be a webclient or a pipestream, or anythign, doesn't matter. Granted this is by design: Its a Bad Design! or least a very limited one at that. I want to say 'Check Buffer' saying if there is something in the buffer read it, if not, return null, 0, whatever. In order for it to handle the way I want it to handle, i'd have to then do: BufferStruct.ReadBuffer() pipestream.beginread() do until _bufferread : application.doevents : loop end PipeStream Buffer Read Event _bufferread = true pipestream.endread() end (Effectively, since the above is Total psuedo code) That defeats the purpose of async reading. Your brain is smarter than any micro-chip.'Д«ut using BeginRead is Asynchronous, so I won't know if there is something in the buffer until the async event triggers.

#Step 7 micro win full or half duplex how to#

Any suggestions on how to resolve this 'Read with nothing is there' issue? Thanks Jaeden 'Sifo Dyas' al'Raec Ruiner

#Step 7 micro win full or half duplex code#

This is quite disturbing and still involves a lot of weird exposed code in my main applicaitons instead of having it streamlined and encapsulated they way i desired just because the Read attempt wasn't written to fail if nothing is there. However, since it exists on another thread the exception isn't raised on the current thread that's executing the failed Read() operation.

I thought about trying to create a small timer, as the Timer class exists on a different thread, and have the timer like elapse after 25 milliseconds and raise an exception. for some (and i think idiotic) reason if there is nothing in the Pipe to read, the command PipeStream.Read() just dies, but not in a good or foreseeable manner, it just sits there doing nothing until there is something in the pipe to read then it's okay, but since it is hung up a message never appears in the pipe to end the hiccup. The problem lies when one side of the equation doesn't send any thing. It coudl respond with an Error, or perhaps the Transmission from the client was a request, but either way it has to respond, and thus when the client receives the response it proceeds with the next step, and vise versa. So I send something from client to server, the server must at the very least respond with an OK flag, indicating it received and processed the message. I've had to, to avoid this problem as much as possible, devise the entire design as half-duplex send-response checks. I'm using message mode as i've formulated my own messages and a standardized communication pattern, as well a full event driven wrapper around the whole process, but it all fails because of one simple little error: PipeStream.Read(buffer, 0, 4) Yes, part of my design has simple checks and waits for when a command comes in. The issue is this, you have a NamedPipeClientStream and NamedPipeServerStream, and they basically communicate back and forth.

Naturally, I call it a glitch because it doesn't even raise an exception it just hangs. Well, I've worked with the PipeStream class for cross process and inner process communication, and so far have devised as many ways as possible to get around a glitch in the system.