Limits of Winsock server - Experts?

[DigiRev]

I'm real experienced with Winsock/VB (that's what I spend most of my time doing), but I've never actually ran a server that used Winsock that handled more than even 20 connections at a time.

I'm making an instant messenger client/server in VB, and I'm wondering how well a server that supports over 32,000 simultaneous connections would handle? Assuming it was coded properly and the data parsing and other functions were completely optimized? What kind of computer would it take to handle this kind of server?

Should I consider multi-threading? What kind of computer should I build to host the server? Or should I find a dedicated server?

Writing/optimizing the code is no problem, but I just want to know what to expect.

If you're just going to post something like "Write it in C++" at least state WHY.

Thanks.

[CVMichael]

I'm sure winsock would be able to handle that many connections, but are you sure your code does ?

I don't think anyone made a server that can take that many connections, I think you will have to make a test somehow... (don't ask me how, cuz I have no idea)

I think it all depends on how much data is transfered for each connection, and how fast you process it.

Whenever you receive data, while you process that data in your DataArrival event, winsock will buffer the incomming data, and when you exit from the DataArrival, then it will call the event again and return the remaining data.

So the idea is that you have to process the data extremly fast for something like this, otherwise winsock will buffer to much data, and there will be too much latency...

If I were you, I would make key functions (heavy processing functions) in a DLL in C++, and use the DLL like APIs to have the fastest processing time. Also, I would consider putting the winsock in a different thread, and make your own buffer with the data in a second thread (i.e. don't let winsock make the buffer because winsock might drop data if the buffer gets to big), I mean, in cases like this, I would not rely on winsock...

[Al42]

You may want to look at Bahamut code (or something similar) to see how the big IRC networks handle thousands of connections. (Anything over a few thousand is usually "handled" by having multiple servers.)

[DigiRev]

I'm sure winsock would be able to handle that many connections, but are you sure your code does ?

I don't think anyone made a server that can take that many connections, I think you will have to make a test somehow... (don't ask me how, cuz I have no idea)

I think it all depends on how much data is transfered for each connection, and how fast you process it.

Whenever you receive data, while you process that data in your DataArrival event, winsock will buffer the incomming data, and when you exit from the DataArrival, then it will call the event again and return the remaining data.

So the idea is that you have to process the data extremly fast for something like this, otherwise winsock will buffer to much data, and there will be too much latency...

If I were you, I would make key functions (heavy processing functions) in a DLL in C++, and use the DLL like APIs to have the fastest processing time. Also, I would consider putting the winsock in a different thread, and make your own buffer with the data in a second thread (i.e. don't let winsock make the buffer because winsock might drop data if the buffer gets to big), I mean, in cases like this, I would not rely on winsock...

Thanks, CVM. That's a good idea about having the key functions written in another C++ DLL. My main worry is multi threading, because I want it to be stable, but I also don't want it to only be able to process one thing at a time. With 32,000+ connections, the parsing code in the DataArrival event would be executing constantly. There would probably be latency when sending messages, etc.

If I were to write some functions in C++ and call it from the DLL, wouldn't that still execute in the same thread as my program?

You may want to look at Bahamut code (or something similar) to see how the big IRC networks handle thousands of connections. (Anything over a few thousand is usually "handled" by having multiple servers.)

I was considering making multiple servers, but then 2 clients that are on different servers would not see each other. I would have to develop a server-to-server protocol and that would just slow things down a lot.

I wonder how Yahoo, or MSN does it?

I could make a central database somewhere that all servers read/write to, but I don't know what kind of database it would be, where I would put it, and how I would connect to it. I've tried MyOBDC before unsuccessfully because the server didn't accept remote connections.

I'm at a loss. :sick:

[dilettante]

I've experimented with this some.

By writing the server very carefully I had no problem getting to around 600 connections. However the server was doing very simple processing, basically just accepting client input and doing a StrReverse() on it and returning the result. This was on a PII 400 machine with 384MB of RAM running Windows 2003 Server Enterprise Edition.

Then I found a number of registry settings that had to be tweaked. There are several "server health and safety" limits set at low (or high) defaults in Windows. These can be tweaked up (or down) but you need to know what you're doing and you don't want to leave just any server's settings this high (or low... as the case may be).

Some of the tweaks only work in a server version of Windows.

I was finally able to push a VB6 single-threaded socket server using the Winsock control to around 2300 clients before I ran into errors.

http://www.xtremevbtalk.com/showthread.php?t=273881


Multithreading will only buy you so much. My finger-in-the-wind guess is maybe double. With a two-CPU machine (maybe even a dual-core or just a hyperthreading machine) multithreading may let you at least double it again.

"Thread per user" is a sucker's bet. Unix programmers do this and everything ends up fighting for a CPU slice. Thread-switching eats up too much of the CPU on overhead, though it may be lighter-weight than doing the same thing under Windows. I'm constantly amazed at how primitive Unix is in many ways, but some of this works to your advantage at times too. And for a chat server you'll have to have a lot of IPC going on to let the threads interact.

Keep your server down to no more than two threads per processor. Perferably structure it with a control thread and one or more worker threads, to make scaling easier as you add CPUs (or HyperThreading pseudo-CPUs).

To do better yet would require a faster computer with more RAM (no problem today) and you'll want a NIC that supports offloaded TCP. This moves a good chunk of the TCP stack onto a smart network card that has a lot more RAM of its own than a regular card. Of course you have to tell the OS that you have this kind of card, and enable TCP offloading first. This will free up a lot of CPU cycles for your server program to do actual work with.

Another possibility is to discard the Winsock control and program against the Winsock API using Overlapped I/O and Completion Ports. This gets messy in VB but will probably buy you some performance and allow more connections to be handled as well. Just using the Winsock API in normal sync or async mode probably won't buy you much over using the Winsock control... and you might actually do worse! The Winsock control has a lot of "smarts" in it.


Going beyond this requires getting a little fancier.

The old way this was once done for both SMTP email and for IRC chat was a form of load sharing. Separate computers acted as servers each handling some fraction of the user population. To keep everyone in sync, the servers were arranged in a relay network (some used trees, some used redudant cycles or circles of servers, rarely star configurations).

In addition to the crowd of clients they were connected to, each server was connected to 1, 2, or a few other servers. So everyone typing to Server A who was in a chat with users on Server C would also have their traffic multiplexed over a single link to Server C (which might travel from Server A to Server B to Server C).

If Server A gets too busy, it could accept a client connection briefly and return a "redirect to Server B" message. Then the client would disconnect from A and connect to B to try again, and so on.

Newer load-balancing schemes exist today, but they generally require special routers as well as special tricks in the server software. Sometimes a set of load-balanced servers will talk to each other over a very high speed (today at least 1Gbps) private LAN "behind" all of them. Things like Storage Area Networks (SANs) often do this as well, and sometimes they don't even use TCP on the back-LAN but instead use a special file access protocol to optimize use of that network.

[DigiRev]

Wow this is very discouraging. That's a very helpful post, dilettante. I'm reading through that thread you linked to also.

I've always wondered why the Winsock control was async while the API was not. (MsgWaitForObject()? etc).

What would you do in my situation? This instant messenger is going to have a very high load. You said you got your server to around 600 connections and that was for just simple processing? :sick: The actual estimated average throughput of this server won't be too high, just chat messages and other things. I'm keeping the protocol real short and simple.

But with a lot of users on at once, it would add up quick. Real quick. :sick:

I could deal with a little latency but not much. I may also need to admin the server so I can't have it hanging while trying to administrate it, or administrate it and cause it to hang for clients.

Would I be better off just building several computers and hooking them up on a LAN and running different servers on each one to share the load?

Even then I don't think I could get/afford a dedicated connection at home. Where would I host this server?

I'm starting to realize I knew much less about this than I thought I did.:(

[CVMichael]

I'm starting to realize I knew much less about this than I thought I did.:(
Same here :D
The applications I made in the past had like 100-200 connections, and it was working fine... I assumed it will work just as fine with more connections especially with today's computers (dual core + lots of ram), but I guess I was wrong :)
So it looks like you have to make multiple servers, and figure out how to do load balancing... quite tricky... (don't ask me how to do it though, cuz I don't know, though I can assume how it would be done...)

[dilettante]

Actually the API can be used in an async manner. After all, the Winsock control is just a wrapper on the API that also provides a few extra services.


From the results of my experiments I think you have a few options. Some of them depend on the chat protocol you'll be using. Are you writing your own client? Do you have the freedom to be as innovative as you want with the protocol?

If so, you might try something like have a server that acts as the "major domo" so to speak. This guy would accept initial connections from clients and tell them where to connect to for chatting.

The "Major" as I'll call him will probably manage "Room" lists and such, keeping track of what "Tables" are in each Room. Each Room would be managed by a "Waiter."

A Waiter would be an instance of your actual chat server. Single threaded should be fine. You might design each Table for a maximum of N seats, maybe 100? Here a "Table" is more like what we'd think of as a chat room.


So when a client enters and meets the Major they request a Table ("I'm here for the Johnson Party"). The Major checks his Room list to see if a Table has been set up for the Johnson Party.

If so he directs the client to connect to the proper Waiter.

If not, the Major checks for a Waiter who isn't too busy and directs him to set up a Table for the Johnson Party. Then the client is sent on to that Waiter.

If a Waiter gets too busy (too many clients) he can ask the Major for help. The Major sends in another Waiter (starts another Waiter server) assigning him to help out with the Johnson Party and the rest of the Tables in the first Waiter's Room. These Waiters begin cooperating, handling all of the clients seated at all of the Tables in that Room.


So there's a lot of communication going on. Each Waiter may have to work with others to handle the Tables and pass chat around, but each client is attended by just one Waiter.

Assuming that the "in house" chatter among the "staff" can cross machine boundaries (a shared database and possibly broadcast UDP chatter like "Fred at the Johnson Party table says "Hoo hah!") the Major and the Waiters don't all need to be on the same machine. Maybe just on the same LAN segment.

For client connections maybe the Major gets one TCP port number and each Waiter gets another unique one?


By using more modern hardware than I tested on, you might get away with as many as 2000 clients per processor. Maybe even as many as 4000 per processor if each CPU or core is in the 2GHz range with a lot of RAM.

Remember however (since you read that other thread) that my test server got most stressed out by accepting huge numbers of new clients rapidly. If clients arrive staggered over time and stay awhile you might do a lot better!

A HyperThreaded Core 2 Duo box (or AMD equivalent) with 2GB of RAM... maybe you could handle 15,000 or so per machine?

At a certain point though the chatter itself is going to be the big bottleneck. There is a lot of "bookkeeping" to do, and all of the "in house chatter" has a price too.


THE FIRST THING I'D DO though is try repeating my tests yourself, on better spec hardware than I was using.

After that, start changing the parameters of the test to reflect a chat application better. Spread out the arrival rate on new connections. Have some more random chatter sent and received by the clients. Simulate chat rooms, and have chatter sent by one client connection echoed back out to several other chatroom member connections.

Also, if possible, get your hands on a NIC that supports TCP offloading and test with that.

It is not impossible to find a hosting company that will offer these "smart NICs" and probably on a Gigabyte LAN as well. Having them connect two or more machines on the same LAN segment is probably far from impossible too.

Even asking for dual-homed machines (two NICs) with the "second adapters" all connected on a private LAN may be possible. All of the database access and in house chatter could go over that LAN. This may be beyond what's needed though.

[dilettante]

The applications I made in the past had like 100-200 connections, and it was working fine... I assumed it will work just as fine with more connections especially with today's computers (dual core + lots of ram), but I guess I was wrong.
No, you aren't wrong.

As long as you use a server OS and tweak those registry settings a more modern machine will do better. The question really is how much better.

But the big problem with one VB server with one big Winsock control array is... imagine the cost of looping through them all to pick out the ones currently connected and active and in the same chatroom??

Either a bit of multithreading will be needed, or several separate server processes coordinating effort, or at least using something like separate Winsock control arrays per chatroom?

Anything to cut down on having one long-running loop to scan through all of the connections in one shot every time a chatter hits Enter. ;)

[DigiRev]

Lots of good info to digest but I'm feeling constipated :p

I ran a test on my computer connecting to my friends computer over the internet.

Not a complicated test, and doesn't reflect a chat system much. Remember that my chat program will be just like Yahoo (buddy lists/status messages, lots and lots of chat rooms, user rooms, and a lot more).

I had each client (winsock) send 100 delimited packets to the server and the server just bounced those packets back. But the server was still splitting the packets/psuedo-processing them as the real chat server would.

I was just mainly wanting to see how many connections I could get on the machine (XP Pro).

I got up to a couple thousand (with data going back/forth) before he got an error which I still haven't looked at yet.

I noticed that the failed connection attempts happened when trying to connect a lot of clients quickly (as you said). This isn't that much of a problem. I can just make the messenger re-try/pause a certain number of times before giving an error message.

Either way, 2000 active connections is a lot better than I had expected after doing some reading. And it might be good enough for a little while anyway.

I am still going to try and do as you said...write a "master server" and other "waiters" as you called them to act as individual servers.

If the server computers are networked and on a LAN, then it shouldn't be too much of a bottleneck.

Also, to answer your first question: yes, i have complete control over the client/server and server/server protocol. I'm writing this all myself.

Thanks for all the helpful replies so far Dill and CVM

[dilettante]

That's pretty good!

My tests probably failed to take into account what a slower network in between does to things. I was testing with two machines back to back on a dedicated 100Mbps LAN.

Like I said, accepting large numbers of connections quickly was the really sore point. Maybe I should try testing something more realistic, not getting new connections so rapidly.

This may invalidate a whole lot of my findings. Of course I was just trying to break the 64 client limit at first, and then the 600 client limit. Clearly there are a lot more factors at work when you consider a real application.

Who knows? Maybe you'll really get this working without a rack full of servers! Great news.

[DigiRev]

Who knows? Maybe you'll really get this working without a rack full of servers! Great news.

That's what I hope. :) At least until it's popular enough to where I have enough saved up to do that if I need to.

Thanks for all the great help, that thread (and your replies) helped a lot!

[zynder]

Thanks for the link Digirev. Now i'm overwhelm with information. Suddenly, I'm having doubt if I still want to continue with my IM project. /sob.

Hey Digirev, make me your apprentice. :)

[DigiRev]

Thanks for the link Digirev. Now i'm overwhelm with information. Suddenly, I'm having doubt if I still want to continue with my IM project. /sob.

I felt the same way.

But after some testing it seems the server can actually accept a lot of connections. But I just won't know how well it will handle that many connections until it's finished.

I tested again with the same basic test and 8,000 out of 8,000 connections were successful with a delay of 100ms between each connection. The server handled fine and it's not even that great of a computer.

Haven't tested anymore than that yet.

Hey Digirev, make me your apprentice. :)

:p

[zynder]

:eek: 8000 connections? Aw! I can't even test a single connection here. I tried it on LAN and it's working fine. I don't have any dedicated server here at least I could have a test run.

Hey, Digirev, can I have one of your executable IM client? let's give it a test run. :D Im from the Philippines let's monitor the latency.

[DigiRev]

:eek: 8000 connections? Aw! I can't even test a single connection here. I tried it on LAN and it's working fine. I don't have any dedicated server here at least I could have a test run.

Hey, Digirev, can I have one of your executable IM client? let's give it a test run. :D Im from the Philippines let's monitor the latency.

I wish I made it that far. :) It's in its (very) early stages. Right now I'm working mainly on design (which I suck at), which means making a lot of custom controls from scratch (command button, frames/panels, tabs, etc.).

So right now it looks like crap but I'm working on it. When I have it ready I'll be sure to let you test it with me.

If you want to see what the crappy design looks like so far:

http://www.getmyim.com/login.gif
http://www.getmyim.com/main.gif

[sneakers]

I am new to this forum and just read this thread on your chat program. If this is a simple chat program like messenger (1 on 1 chat or chatting with a few buddies from your list) then all a server will need to do are these few functions.

1) Keeping a list of every client that is currently logged in along with their IP address.

When a client logs onto the server then these things need to happen. The client's user name and IP address is recorded to the list of current connections AND each member on the client's "list" needs to be checked to see if they are connected or not. If they are connected then your client needs to show them as active in your client list and store their current IP address on the client's computer.

2) Ping clients to keep the list up to date.

This will check to be sure everyone on your list is still logged on and active. If a client logs off by just turning off their system or being disconnected from the internet then the server will know and update the list of current connections.

Although this may sound very simplistic, in reality it isn't. Consideration will need to be given for issues like notifying a client of those user's which show disconnected due to a failed ping reply. Should this be a function of the server or should each client ping the members of their own list? Should a client ping the members of it's own list rather than the server doing all of the pings?

There are many issues like this but the bottom line is this...
Do everything you can with the client. Keep as much traffic off of the server as possible. There is no reason for every single character typed to have to pass through the server.

Chatrooms are a different animal than a messenger type of chat service. With messenger chats, most things that are handled by the server in irc chat can be handled by the client.

By doing this, how many connections can the winsock control handle safely is no longer the issue. The issue then becomes how fast can the winsock control record the newly logged on user's information and poll the members of that user's buddy list. Once this is done that user is released to do his own thing making room for another user to logon and be on his way.

If you are able to connect 8,000 clients at once to your server, how many clients can be logged on if all the client does is to spend a few seconds logging on and polling the members of it's list then is released from the server to make room for another user logging in? I'm not sure if 8,000 connections would even be needed.

Something else that might be done is this...
If this is just simple chat without the need to double verify each and every character sent between 2 parties then use the UDP protocol. The UDP protocol has much less overhead (data testing and checking) than does TCP but the data is not checked for errors. Unless I was exchanging technical information, I wouldn't worry about data testing and checking. You may wish to use TCP for file transfers or make it an option for users who do exchange tech information in a chat program.

Regardless of which protocol you use, the goal is for the client to do as much of the work as possible to free up server resources. Logon a client as fast as possible and release that client from the server as quickly as you can.

In this scenario the major resources of the server will be used to ping clients. If the clients do all of the pings then the server's resources are still available for other issues. This opens another can of worms like how to tell if the users in your list are online or how is the server notified if a client is found to have disconnected? Does the server even need to know if a client has disconnected or would the server just keep a list of all clients and last known IP address. etc. etc. etc.

Hopefully this will help you be able to support as many clients as you would ever have without using a bank of computers and dedicated servers.

[DigiRev]

Thanks for the reply.

I am new to this forum and just read this thread on your chat program. If this is a simple chat program like messenger (1 on 1 chat or chatting with a few buddies from your list) then all a server will needs to do are these few functions.

No, this is an instant messenger (Yahoo!, MSN, AIM, etc.).

1) Keeping a list of every client that is currently logged in along with their IP address.

When a client logs onto the server then these things need to happen. The client's user name and IP address is recorded to the list of current connections AND each member on the client's "list" needs to be checked to see if they are connected or not. If they are connected then your client needs to show them as active in your client list and store their current IP address on the client's computer.

Yup...

2) Ping clients to keep the list up to date.

This will check to be sure everyone on your list is still logged on and active. If a client logs off by just turning off their system or being disconnected from the internet then the server will know and update the list of current connections.

Although this may sound very simplistic, in reality it isn't. Consideration will need to be given for issues like notifying a client of those user's which show disconnected due to a failed ping reply. Should this be a function of the server or should each client ping the members of their own list? Should a client ping the members of it's own list rather than the server doing all of the pings?

No real need for pings. When a client disconnects the Winsock_Close() event fires and from there the server can tell the client that one of their contacts has gone offline.

Sometimes, though, that event doesn't fire (if the connection times out). In which case you're right about pings, but the connection can be kept alive simply by sending a few bytes of data every so often. If sending fails then I can do what I would in the Winsock_Close() event.

There are many issues like this but the bottom line is this...
Do everything you can with the client. Keep as much traffic off of the server as possible. There is no reason for every single character typed to have to pass through the server.

I think you're right in that it would help the server performance but it would also increase the risk of exploits and security holes. I don't want my messenger to have that problem like other ones (Yahoo!, MSN, AIM), etc. Where people make booter programs to kick others offline, make spam bots, etc.

Something else that might be done is this...
If this is just simple chat without the need to double verify each and every character sent between 2 parties then use the UDP protocol. The UDP protocol has much less overhead (data testing and checking) than does TCP but the data is not checked for errors. Unless I was exchanging technical information, I wouldn't worry about data testing and checking. You may wish to use TCP for file transfers or make it an option for users who do exchange tech information in a chat program.

UDP would be a bit faster but at the expense of dropped packets. If I were chatting on a messenger it would get pretty annoying is some messages didn't send correctly, or at all.

Regardless of which protocol you use, the goal is for the client to do as much of the work as possible to free up server resources. Logon a client as fast as possible and release that client from the server as quickly as you can.

You're right, that would free up a lot of resources from the server and I actually never really thought of doing it like that. In a simple IM program that might work ok, but there has to be some sort of server for chat rooms and everything else. Especially since most things on the IM will be directly related with the website/database (profiles, etc.).

Thanks again for the reply.

[sneakers]

UDP would be a bit faster but at the expense of dropped packets. If I were chatting on a messenger it would get pretty annoying is some messages didn't send correctly, or at all.

I don't think that UDP is a "shoestring" type protocol in that it isn't reliable. It is as reliable as TCP but without the error checking. This is a guess but I would guess that TCP rarely has to resend a packet and UDP would be just as reliable. If I were going to be transmitting tolerances for the space shuttle or formulas for dangerous chemical compounds then TCP would be my choice but for everyday chit chat, UDP would work fine. Surely UDP is as reliable as a telephone conversation.



I think you're right in that it would help the server performance but it would also increase the risk of exploits and security holes. I don't want my messenger to have that problem like other ones (Yahoo!, MSN, AIM), etc. Where people make booter programs to kick others offline, make spam bots, etc.

What could a server provide as safeguards that couldn't be built into the clients interface? If the only way that a user could find your address to communicate with you is through the server then how would you being released from the server make you vulnerable to attacks or exploits? Doesn't MSN, Yahoo and the others use a server as the hub for all of their messaging and arent they exploited?

The only reason in which a person would spend time to "crack" your chat system would be if it was very popular with many users. The mere fact of hackers trying to manipulate your system would mean you have a successful package and if you are successful to a degree of attracting hackers then nothing is going to stop them. Windows users have problems with hackers because of the volume of users. This huge volume of users look attractive and worthwhile to those who wish harm. Users of Apple operating systems do not seem to have this trouble. People might say it is a totally different machine without the security holes of a machine running windows. Linux uses the same machine as Windows and they don't seem to attract hackers either.




You're right, that would free up a lot of resources from the server and I actually never really thought of doing it like that. In a simple IM program that might work ok, but there has to be some sort of server for chat rooms and everything else. Especially since most things on the IM will be directly related with the website/database (profiles, etc.).

Of course a server is needed. Just keeping up with new user registration would require a server. Users filling in profiles and submitting them to the server would require a server but downloading and reading a profile can and should be done from the client's user interface. Chatrooms usually require a server. Some of the messengers do allow for group chat which in theory is a chatroom but this too could be handled by the user interface. I thought your post said that you are creating a program like IM

I'm making an instant messenger client/server in VB, and I'm wondering how well a server that supports over 32,000 simultaneous connections would handle? Assuming it was coded properly and the data parsing and other functions were completely optimized? What kind of computer would it take to handle this kind of server?

An instant messenger client/server is not the same thing as msn chat or buzzen or even some of the irc chatrooms. Which of these are you wanting to create? Are you wanting to put both messaging systems and chatrooms together in some type of format?

As far as your question above is posed, what type of computer would be required to handle a server for an instant messenger client/server, I would have to say not nearly as big and fancy of a computer as it may seem at first glance if careful consideration is made as to how each event will be handled and by who.

[dilettante]

Another issue is the non-paged pool memory and locked memory pages used "under the covers" by the underlying Winsock stack.

Chapter 6: Scalable Winsock Applications (continued) (http://www.microsoft.com/mspress/books/sampchap/5726a.aspx) covers some of this, but from the perspective of a programmer using the Winsock API and overlapped I/O.

[DigiRev]

I don't think that UDP is a "shoestring" type protocol in that it isn't reliable. It is as reliable as TCP but without the error checking. This is a guess but I would guess that TCP rarely has to resend a packet and UDP would be just as reliable. If I were going to be transmitting tolerances for the space shuttle or formulas for dangerous chemical compounds then TCP would be my choice but for everyday chit chat, UDP would work fine. Surely UDP is as reliable as a telephone conversation.

I've actually created several programs that used the UDP protocol and it is NOT reliable enough for me.

What could a server provide as safeguards that couldn't be built into the clients interface?

The whole point is the protocol has to be safe. I don't want people making 3rd party clients. Building safety measures into the client will only prevent someone exploiting the system from that CLIENT. It does nothing to prevent people from making their own.:rolleyes:

but downloading and reading a profile can and should be done from the client's user interface.

Uh huh. But profiles are not just available on the website they will also be tied into the messenger. For example, holding your mouse over a contact in the list will show their profile information from the database.

An instant messenger client/server is not the same thing as msn chat or buzzen or even some of the irc chatrooms. Which of these are you wanting to create? Are you wanting to put both messaging systems and chatrooms together in some type of format?

Most instant messengers also have chat rooms. Not just private messaging. If you've ever used Yahoo! then you will know what I'm talking about. This will be the same. But it will be a little different in the features and have better security and much more options.

[dilettante]

No, UDP is not reliable. This is by design.

Any network device (router, switch, TCP/IP stack at the receiver) between the sender and receiver is allowed to throw away UDP datagrams for any reason, usually network congestion or just being busy. Individual packets can be corrupted as well, and be discarded.

TCP segments can be discarded in the same way.

The difference with TCP is that the sender must await an acknowledgement and retry any lost segments. The receiver must buffer and store segments so that they can be delivered to the receiving application in the proper sequence, and if it gets busy it can send a "push back" signal to the sender to throttle bandwidth.

So with UDP, datagrams can just disappear entirely or be received in random order. It is a trade-off between reliability and speed.


Try entering:

netstat -s

.. at a command prompt to see the current statistics.

[DigiRev]

Try entering:

netstat -s

.. at a command prompt to see the current statistics.

Nice, used the netstat command a lot but never used the -s switch. Here are my results.


IPv4 Statistics

Packets Received = 216036
Received Header Errors = 0
Received Address Errors = 639
Datagrams Forwarded = 0
Unknown Protocols Received = 0
Received Packets Discarded = 1
Received Packets Delivered = 216035
Output Requests = 185986
Routing Discards = 0
Discarded Output Packets = 0
Output Packet No Route = 0
Reassembly Required = 0
Reassembly Successful = 0
Reassembly Failures = 0
Datagrams Successfully Fragmented = 0
Datagrams Failing Fragmentation = 0
Fragments Created = 0

ICMPv4 Statistics

Received Sent
Messages 356 21
Errors 0 0
Destination Unreachable 336 1
Time Exceeded 0 0
Parameter Problems 0 0
Source Quenches 0 0
Redirects 0 0
Echos 20 0
Echo Replies 0 20
Timestamps 0 0
Timestamp Replies 0 0
Address Masks 0 0
Address Mask Replies 0 0

TCP Statistics for IPv4

Active Opens = 2420
Passive Opens = 54
Failed Connection Attempts = 35
Reset Connections = 405
Current Connections = 11
Segments Received = 149783
Segments Sent = 137224
Segments Retransmitted = 249

UDP Statistics for IPv4

Datagrams Received = 65244
No Ports = 1004
Receive Errors = 0
Datagrams Sent = 48138


I typed: netstat -s >C:\netstatout.txt so it would put the results in a text file.

[zynder]

Cool. I'm used to netstat -n and -a.

Hey Digirev, your design is simply great. That's fine with me as long as it's loaded with functionality. Design comes next.

[DigiRev]

Cool. I'm used to netstat -n and -a.

Hey Digirev, your design is simply great. That's fine with me as long as it's loaded with functionality. Design comes next.

Making it functional is what I'm a little worried about. ;) :p

This is what I've decided to do in case anyone is interested.

2 different kinds of servers. 1 is a master or "switch" server. All clients connect to this FIRST. The switch server will tell them which main server to connect to (the least busiest one), or if all servers are busy. It will tell them which server IP/Port to connect on. This way I can run more than 1 server on a computer (instead of multi-threading), or on different computers.

All servers and the switch server will be on a LAN, so they can can communicate to each other quickly.

There will be a central database on the switch server that stores who is online, who is in what chat room, etc. All servers will read/write to this central database instead of communicating to each other for everything. This way, they all know the same thing (who is online, etc.).

Now the questions arise:

What kind of database? Accses? SQL?
What kind of potential problems do you think I will have doing it this way?

So, in summary:

Client -> Switch server -> Re-directed to main chat server

Main chat server -> Central database -> Client

Hope this makes sense, I probably didn't explain it too well. :o