-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0|462|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
SoCoder -> Snippet Home -> Networking


 
Afr0
Created : 19 July 2010
Edited : 21 July 2010
System : Server Based
Language : C/C++

Packet

A generic Packet class

Here's a generic packet class that I just made.
I don't know why... but it seems the absence of programming that occured after I quit school has begun to catch up with me ever so slightly!



If I may say so myself, this is, aside from being a perfectly functioning Packet class, a good example of OOP.
So for people like Jay who are afraid of OOP, this might be worth studying!

 

Comments


Monday, 19 July 2010, 06:47
Jayenkai
Not worth studying.. Too Scary!!!!

It's even got error messages, and everything! AARRGGHH!!
Monday, 19 July 2010, 10:02
Afr0
Update: Added some methods for writing safely to the packet's buffer, I.E taking the packet's length into account.
Tuesday, 20 July 2010, 15:10
Afr0
Update: Added a method for peeking Int32s from the packet's buffer. If you need to peek some other types, you should have no problem coming up with a method yourself from looking at the code.
Tuesday, 20 July 2010, 21:53
JL235
I would advise having methods throw exceptions rather then write to the command line. If I call 'PeekInt32' I am not expecting it to perform printing.
Wednesday, 21 July 2010, 07:51
Afr0
That is a question of design. Making unique exceptions for classes to throw, or even just throwing a standard exception, means the user has to write code to handle those exceptions.
I prefer to handle the exceptions within the methods.
Wednesday, 21 July 2010, 08:09
JL235
Ok, then lets say I use your code and a packet I am reading is incorrect. As a developer, how can I be informed my packet is incorrect and so write code to deal with it (like ask for the packet to be resent) when the error is being printed to the console?
Wednesday, 21 July 2010, 09:05
Afr0
Quite frankly I wrote this code to be used for a server application. Server applications should be console apps, not Window(s) apps.
That said, when developing a networked application you end up looking at data sent through the wire all the time in some form or another.
The chance that you will not know if a packed received didn't contain all the data it was supposed to contain is remote.
And even if it didn't contain all the data, that is more than likely a problem with the way you're receiving or sending the data rather than a problem with the way you're reading the received data from the packet.
The reason I even bothered to catch exceptions at all was as a last-resort thing rather than a 'end all be all' of my network infrastructure.
Wednesday, 21 July 2010, 09:14
Afr0
Update: Added code to ensure that people who likes writing code for dealing with unneccessary exceptions can do just that!
Wednesday, 21 July 2010, 09:29
JL235
Afr0 Quite frankly I wrote this code to be used for a server application. Server applications should be console apps
Actually most server apps are background programs, neither console or window. So in practice any error output sent to the console will just be lost. Saving to a log file more common and this also means you automatically have this saved on disk.

No one is going to have a console open permanently whilst the WoW servers are running. It'll mean the app is dependent on the terminal being open, which in turn is dependent on someone being constantly connected to the machine. If they lose their connection then the server will go down too (as it's running from their terminal session which would have closed).
Wednesday, 21 July 2010, 17:13
Afr0
Actually most server apps are background programs, neither console or window. So in practice any error output sent to the console will just be lost. Saving to a log file more common and this also means you automatically have this saved on disk.

No one is going to have a console open permanently whilst the WoW servers are running. It'll mean the app is dependent on the terminal being open, which in turn is dependent on someone being constantly connected to the machine. If they lose their connection then the server will go down too (as it's running from their terminal session which would have closed).


Most server emus are not background apps, but console apps. But I see your point. It really comes down to whether you are physically or remotely controlling your server.
I know Blizzard are physically controlling their servers, for instance, as they have a serverfarm in EU and North America. So the WoW server app could be a console app.
Thursday, 22 July 2010, 00:15
JL235
Being able to open up a terminal and interact with their server software is not the same as running the software itself directly within a remote console. They might start it from a console, but it'll be spawned to go off and run on it's own so that the user can close their console.

It just doesn't make sense to have such important software running directly within a users console.
Friday, 23 July 2010, 21:38
Afr0
They might start it from a console, but it'll be spawned to go off and run on it's own so that the user can close their console.


Why should the user close their console? Why should they do anything else but use the console?
The server is supposed to be dedicated, I.E not used for anything but running the serversoftware and act as a terminal through which to operate it.
Saturday, 24 July 2010, 08:02
JL235
Afr0 Why should the user close their console?

Because they will want to disconnect from the server. Hundreds of reasons why they would want to disconnect.
Saturday, 24 July 2010, 13:24
Stealth
Then just run it as a process on the server instead of a console application. The way Afr0 is doing it isn't that big of a deal.