decrypt Posted April 16, 2005 Posted April 16, 2005 Ok, I made an msn bot in visual basic.net a while ago in windows forms, and I want to make it into a console application. I have run into one major problem though. In my windows application version every chat session ran in a different window. Is there any possible way to simulate or do this with a console application? Thanks in advanced --decrypt btw, I am using vb.net Quote
Wile Posted April 16, 2005 Posted April 16, 2005 I don't think multiple threads will do the trick (actually multiple windows will all run on the same thread). What you probably want is mutilple chat screens somehow. I dont think it is possible for one application to open more than one console window. I dont know if you know IRC, it is a chat system that has been along for a VERY long time (i know i had an IRC client on an old 486dx2 running in DOS). That also allows multiple chat channels. What those DOS clients did was implement there own alt+tab like behavior switching from one channel to another. What you could do in your console app implement some kind of chat switcher key, and on that key go to the next chat / show a list of active chats. If I recall correctly, the IRC client showed a list of all active channels, and they would light up in a different color if something was said in them. But it won't work as simple as a graphic version of a chat client. Quote Nothing is as illusive as 'the last bug'.
Mister E Posted April 16, 2005 Posted April 16, 2005 I don't think multiple threads will do the trick (actually multiple windows will all run on the same thread). What you probably want is mutilple chat screens somehow. It's a bot. "Chat screens" are not needed. Multiple threads will work. Quote
IngisKahn Posted April 17, 2005 Posted April 17, 2005 Why would you need multiple threads? A simple queue would work fine. Quote "Who is John Galt?"
Mister E Posted April 17, 2005 Posted April 17, 2005 Why would you need multiple threads? A simple queue would work fine.If you're going to make something, you may as well make sure it's scalable. A "simple queue" would not be scalable. As the number of connections grow, your approach would become more and more cumbersome. Imagine if a web server operated in this fashion. Quote
IngisKahn Posted April 17, 2005 Posted April 17, 2005 Scalable? He writing a chat bot and unless he's running on a multi-proc system more threads would just slow things down. Quote "Who is John Galt?"
Mister E Posted April 17, 2005 Posted April 17, 2005 Scalable?Scalable - The ability of a product to accommodate growth. ...more threads would just slow things down.Hardly. This is flawed thinking. Modern operating systems are the perfect example. Windows itself is a program that, most often, runs on one processor with many different threads. If it were to utilize the batch processing model (analogous to your "simple queue") then I guarantee you that you would not have as pleasant of a computing experience. Batch processing systems went the way of the dodo bird about 25 years ago. It really is simple math. Say the program was using a queue and that the bot was able to service a request in x ms. If there were 20 users using the system then, on average, they each would have to wait 20x ms in order to get a reply! However, if a threading approach were utilized, then the thread time slice would be equal to some very small portion of x. The computer would be doing the exact same amount of work, yet the users would be under the "illusion" that their request was being serviced faster -- much like you with your computer today. Quote
IngisKahn Posted April 17, 2005 Posted April 17, 2005 Please, let's not patronize now. I'm saying that a simple bot app doesn't need to be over engineered. When targeting single processor systems multiple threads should only be used in blocking situations such as disk IO/GUI. Context switching is very expensive. Unless he's expecting thousands of requests per second then there shouldn't be any noticeable delays no matter what approach you take. And your simple math is flawed, if your request is early in the queue then it actually makes it take longer to process (depending on how large your thread pool is). Quote "Who is John Galt?"
Mister E Posted April 17, 2005 Posted April 17, 2005 And your simple math is flawed' date=' if your request is early in the queue then it actually makes it take longer to process (depending on how large your thread pool is).[/quote']First, a multiple thread approach wouldn't use a queue at all. Second, if what you said was true (thankfully it's not) then there would be no benefit to using threads at all -- in any program or situation. Quote
decrypt Posted April 17, 2005 Author Posted April 17, 2005 thanks for the help! I got it to work All I did was get it to reply to the sender :o Quote
IngisKahn Posted April 18, 2005 Posted April 18, 2005 Thread queue. There are many cases where multiple threads should be used. In fact, nearly all UI apps should have the UI on a seperate thread. But a small chat bot won't see any benefits using multiple threads to handle multiple requests. Even if this was a huge chat server, threads wouldn't help unless you're running on a multi-proc system. But that's not what decrypt was asking about anyway. Quote "Who is John Galt?"
Uncle Gizmo Posted April 18, 2005 Posted April 18, 2005 As a bystander, I must say this is a very interesting and fruitful discussion. I hope that you continue it, and maybe if you elivate it to a slightly more professional level, it will be very valuable to others reading it such as myself. Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.