| Tips for a good Server? |
| Barnski | I have made two small servers. Now I'm asking me, what is the real value of a server, what makes a server "good"?
Is it the number of clients it can handle, the speed of its processing ?
Or is it the stability of the program, and the including error handling ?
Is it the protocol and its efficiency ?
My two servers have no included client maximum. But I do not use threads, instead I just process each incoming event/command and send them into a buffer, which will be processed after Winsock has sent the last answer. Does this slow the process down? Is there a way to make it work faster?
The programs are not very stable, because the error handling is poor. I have no On error functions.
I tried to make the protocol very simple, so that the traffic is low. I send Strings which are built up like that:
<cmdnumber> [Optional <seperator> <cmdDescription>] <cmdseperator>
An example (I added a command description for your understanding, but the client has a select case function which resolves a description on the remote host, keeping traffic low):
SendData "101-Connection Accepted."
Like that I can send multiple commands to a client:
SendData "101-Connection Accepted.$102-Account created."
or short:
SendData "101$102"
The client/server adds a cmdseperator to its incomming buffer so that a later incoming command will be attached correctly.
So of course I leave the cmdDescription away, I just use it when the command needs one.
In this example the command 201 tells the number of connected clients to a client asking for it:
SendData "201-3"
I know, the protocol is similar to the ftp. I made once a ftp client/script and I found the protocol easy.
And yes, I do not encrypt the commands. Should this be necessary? Depends on the purpose of the server I guess.
Well what do you think about what makes server "good"?
What do you think about the protocol I use?
I thank you for any suggestions.
PS: I am a beginner in VB; I have more ideas than knowledge, which slows me down enourmously. I will be asking more soon |
| Pc | For a good server the protocol should be like
packetname|data1|data2|data3ƒ
Where | would be the packet delimiter. And ƒ would be the packet seperator. The delimiter is used for grabbing data from the packet easier. You should load it all into a array. the Packet seperator is used for "lag" and such. Most of the time the packets will get sent to fast or lag being sent and double over. With the packet delimiter you can put it into a array and parse them seperate. Heres some sample code on how you would setup your basic Winsock DataArrival event.
Private Sub sckMain_DataArrival(ByVal bytesTotal As Long)
' Declaring Your variables!
Dim pDelimiter As String
Dim pSeperator As String
Dim rData As String
Dim cArray() As String
Dim qArray() As String
Dim i As Integer
' Setting the delimiter/seperator. So it can be easily changed later.
pDelimiter = "|"
pSeperator = "ƒ"
' Put the received data into the string rData
sckMain.GetData rData, vbString
' Throw the received data into a array for splitting up.
qArray = Split(rData, pSeperator)
' This is where we loop thourgh all the packets.
For i = 0 To UBound(qArray)
' Put the seperated packet into another array for checking.
cArray = Split(qArray(i), pDelimiter)
' Selecting this will be the 1st thing before the packet delimiter
Select Case cArray(0)
' If the message before the 1st delimiter is msg this will pick it up
Case "msg"
' Call the message box for the data after the 1st delimiter
Call MsgBox(cArray(1), vbOKOnly, App.Name)
' If the message before the 1st delimiter is msg2 this will pick it up
Case "msg2"
' Lets call the message box twice. to show it was msg2 not msg
Call MsgBox(cArray(1), vbOKOnly, App.Name)
Call MsgBox(cArray(1), vbOKOnly, App.Name)
' And the select case. So we can proceed to looping
End Select
' Lets loop around again for the next packet
Next i
End Sub
Hm maybe ill fix this up and submit it as a tutorial =] hope it helps btw.
|
| Excaliber | Well, not having error handling is just a problem waiting to happen. Powerful, well written and redundant error checking is always a good idea. They can keep your server online if an error happens, or at the least, keep data from being corrupted and shut down nicely.
As to the datastream, its best for the protocol to be as binary as possible. Basically, instead of:
"User: blah|Pass: blah"
you have:
"0blah|1blah"
That saved you 12 bytes of data to be transfered. Granted this isnt that important for the login, but in game stuff it becomes necesary. Binary protocols are harder to read (you spend more time writing down what each number means, then referencing that list), but will save you from uneeded lag. |
| Spodi | What I was thinking is you can have 2 numbers set to identify what kind of data is being sent. So, say you have "00" as your login information being sent from client to server, you send:
"00<username>|<password>$"
$ would be the end character just in case lag happens, it doesn't get cut off, so you just keep adding to the string until the $ is added on. |
| Excaliber | Thats a good way as well. I did that for a remote computer managment app I did once.
I used 3 digits, which lets you have up to 999 different commands (more than enough for just about anything). Then i had a reference list of what each # was.
Very efficient |
| Eric Coleman | You should use bytes for identification purposes. By using 2 digit ascii numbers you're using 2 bytes and only have a range from 00 to 99, if you use a single byte then you can have a range from 1 to 255 minus any control characters such as byte 0 as a packet dilimiter. If you use two bytes for packet identification, you can get up to 65535 different packet types instead of 100. |
| Spodi | Hmm, thats a good idea Eric. I'll keep that in mind =D |