Rough couple of days here.
The legacy application server has been acting up and causing a lot of problems. Unfortunately that means that I’m tied up for hours at a time trying to track down errors, login problems, server performance issues or helping to debug reports that were written four years ago that no one remembers who or for what purpose the report was written.
</rant>
I have been trying to work through some issues with the TcpClient’s ability to stay connected to a custom device that supports telnet. I can make the connection just fine, but after I read from the stream, then write back to it, I unfortunately lose the connection.
Checking the CanRead and CanWrite properties always return true, but reading from the stream was causing an exception. I later sourced this part out to an IO exception because I was reading past the end of the stream…but I was doing that because I was expecting more text coming down the pipe.
Also, there seems to be a significant performance hit when you start to read from a NetworkStream object. When I fire up CMD and telnet into the device I receive the data I expect (namely, the login request) almost instantly; there is a 5-7 second delay using the managed wrappers.
I did, however, manange to wrap up development on my background ping library. This will help the CSRs as they work the helpdesk. There are currently 3-6 devices that as a matter of process we check for visibility with pings when a customer calls in. I am this |-| close to having that fully automated and running for any related device between our head end and the client.
Tomorrow is Thursday. I need visible output for this week’s goals…
No comments:
Post a Comment