Printable View
Quote:
Dim conReader As New StreamReader(con.GetStream)
Dim conCont As String = conReader.ReadLine
It just reads the first line of the server I'm trying to connect to, I want to make it read all the messages that the server is sending.
btw, con is: Dim con As New TcpClient
you might try
Code:dim conCont as string = conReader.readtoend
I need another way please.
What I posted will read the whole stream. If it does not, what happens?
Another way of reading a stream line by line is the following.
Code:Dim conCont As String
do while conreader.peek >= 0
concont = conreader.readline
loop
Strange, that just reads the first few lines of the server. :/ ***
All the lines that the server is sending? Does that mean that the server is sending one chunk of lines and you are only able to read the first X of them, or does that mean that over time the server will send a variety of lines at a variety of times, and you want to read all of them as the server sends them?
What Shaggy Hiker is alluding to is that both approaches (readtoend and readline) will only read what is currently in the stream. Once it hits the end of the last message, the reading process will terminate, even if more content is added a short time later.
You would have to occasionally recheck the server to see if there is any more content to be read. Since you are 'pulling' the data, there is no way to automatically know if there is more content. The server might have some sort of 'push', such as RSS which would automatically notify you when there is new content. This is not something you can initiate from your VB application (it has to be done server side). From client side, you can set up a timer which when triggered goes and looks at the server. Depending on what time delay you have, you will likely have some old and some new content, so you will have to deal with duplicates.
Exactly. I don't know why this isn't possible?Quote:
and you want to read all of them as the server sends them?
It is possible, but the situation stands as John SC explained it. For example, I have a program that also sends out lots of messages. I wrote the program to broadcast the messages, and I also wrote a program that receives the messages. The first program is kind of like the server. It just provides the messages. The second program has to snare the messages as they show up. Frankly, I'm struggling a bit with what an alternative would even look like. For one thing, you could have a queue of messages, and the server would just stuff messages onto the queue that the other end could....well, could what? It would have to keep reading the queue to see whether or not anything new has been added, so how is that different from repeatedly polling the server?
Perhaps it would be best if an event was raised when new content was available. I'd be inclined to write it that way anyhow, which I would do by having a background thread polling for new information (I have such a thing in the UDP class I posted over in networking, but that's UDP, not TCP). Whenever new information was received, raise an event on the UI thread to indicate that new information is ready.
The only other way I could see this happening is if both client and server shared an object such that when the server added to the object, the client could be notified about that. Of course, the idea that two programs located in physically different areas and using different physical memory and processors could share a code object is a bit of a mind bender. Not saying that it has to be impossible, though, and I can think of a couple ways to simulate it using WCF, but you'd still be writing the code yourself, and it would still be just a simulation.