Post

 Resources 

Console

Home | Profile | Active Topics | Members | Search | FAQ
Username:
Password:
Save Password
Forgot your Password?

 All Forums
 VBGamer
 VBGamer
 Tips for a good Server?
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

Barnski
Neophyte

Switzerland
1 Posts

Posted - Oct 07 2003 :  08:35:48 AM  Show Profile  Visit Barnski's Homepage  Reply with Quote
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
Neophyte

USA
3 Posts

Posted - Nov 29 2003 :  07:13:03 AM  Show Profile  Visit Pc's Homepage  Send Pc an AOL message  Send Pc an ICQ Message  Click to see Pc's MSN Messenger address  Send Pc a Yahoo! Message  Reply with Quote
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.




-Pc
Go to Top of Page

Excaliber
Squire

USA
28 Posts

Posted - Nov 29 2003 :  09:25:07 AM  Show Profile  Reply with Quote
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.
Go to Top of Page

Spodi
Warrior

USA
142 Posts

Posted - Dec 05 2003 :  02:49:08 AM  Show Profile  Visit Spodi's Homepage  Send Spodi an AOL message  Click to see Spodi's MSN Messenger address  Send Spodi a Yahoo! Message  Reply with Quote
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.

vbGORE
Go to Top of Page

Excaliber
Squire

USA
28 Posts

Posted - Dec 07 2003 :  10:47:39 AM  Show Profile  Reply with Quote
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
Go to Top of Page

Eric Coleman
Gladiator

USA
811 Posts

Posted - Dec 07 2003 :  9:29:00 PM  Show Profile  Visit Eric Coleman's Homepage  Reply with Quote
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.
Go to Top of Page

Spodi
Warrior

USA
142 Posts

Posted - Dec 08 2003 :  01:03:07 AM  Show Profile  Visit Spodi's Homepage  Send Spodi an AOL message  Click to see Spodi's MSN Messenger address  Send Spodi a Yahoo! Message  Reply with Quote
Hmm, thats a good idea Eric. I'll keep that in mind =D


vbGORE
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
VBGamer © Go To Top Of Page
This page was generated in 0.12 seconds. Snitz Forums 2000

Copyright © 2002 - 2004 Eric Coleman, Peter Kuchnio , et. al.