Jan 18, 2017 01:36 PM
(This post was last modified: Jan 19, 2017 08:04 AM by Barret.)
Project
An easy to setup tcp based server/client concept that acts as a framework on top of the existing tcp functionality of .Net
Demonstration of multiple connections, sending data and latency/uptime computation
![[Image: DaLbPYM.png]](https://i.imgur.com/DaLbPYM.png)
Goal
Allowing to send serialized objects or files in both directions and for easy use front-end
Details
The Event handling explained
The event handling of both instances, client and server, can be assigned to a single method,
the arguments given have a base class that are the same, however the server and client do not share the
same functions and properties of a given EventArg object.
The TcpEvent holds what is happend and the EventArgs holds the included arguments with that event
This way we can use a 'Select Case' construction to make life easy.
To determine who's event we have the TcpEvent has the following functions to find out
After determine who we dealing with its time to cast our sender
Remarks
The server assigns each connected peer a unique ID, this is done to have a fixed reference to a specific connection.
All operations are multi threading, direct Event to GUI operations have to be made cross thread save.
Example for a file transfer from server to client:
And from the client side to receive:
Sending objects across the pipeline
We can basically send anything we want but there is a catch to this concept, if we decide to send a custom object,
it be a structure or class it HAS to be a known reference type for both sides. Thats why i use this Protocol as middle man.
Define you custom objects in there which is then released with the client itself.
Remarks
Transfer of files have a so called ID (As Object) which is used to identify this file for a certain reason, it can be number or string , etc,
as long as this ID object can be serialized everything is fine.
Send content flags explained
The first three flags are only used for the protocol to identify itself to another, not used for our purpose.
Safety
The server has a minimal protection, it does not use encryption however this is easily achieved since we (you) control the payload, all what the Framework does is sending it over a controlled connection.
It does contain some minimal safety features such as a maximum buffer overflow limit and protocol version vertification.
If any client, it be new or accepted, over steps these limits, the server drops the connection immediately, if a packet
is not the way it should (think of checksum or not able to construct the packet) it will drop the received data.
(Default values, 5mb max per payload and protocol version is changeable in the config)
Lag and Latency
The server maintains a threshold latency, if a client is too slow or simply not responsive it will drop the connection.
(Default value i use is 30 seconds)
Final notes
I include the demo app that demonstrates how to use it, if you got a question post them.
If you don't understand the workings of TCP connections, im not trying to be rude, but i am not going to explain that.
I assume you know how this works and i give you this source to extend your effort with your goal in whatever project you are developing.
Source:
- Version: A2 https://dl.dropboxusercontent.com/u/8007...a2.src.zip
- Version: A1 removed
Those that see in the right place, know. Keep that in mind :)
An easy to setup tcp based server/client concept that acts as a framework on top of the existing tcp functionality of .Net
Demonstration of multiple connections, sending data and latency/uptime computation
Goal
Allowing to send serialized objects or files in both directions and for easy use front-end
Details
- Client/Server interaction is Event driven
- Uses queues for handling data to not excessively flood a connection
- Uses constructed packets as communication
- - Uses compression of payload data
- - Performs a checksum for each payload
- - Performs a protocol version check (handshake)
- Uses so called 'Heart Beat' packets to keep alive and measure latency
- Contains a centralized config where all settings can be changed
The Event handling explained
The event handling of both instances, client and server, can be assigned to a single method,
the arguments given have a base class that are the same, however the server and client do not share the
same functions and properties of a given EventArg object.
The TcpEvent holds what is happend and the EventArgs holds the included arguments with that event
This way we can use a 'Select Case' construction to make life easy.
Code
Private Sub Event_Status(Type As TcpEvent, EventArgs As TcpEventArgs)
End SubTo determine who's event we have the TcpEvent has the following functions to find out
Code
EventArgs.IsFromServer
EventArgs.IsFromClientAfter determine who we dealing with its time to cast our sender
Code
Dim args As ServerEvent = CType(EventArgs, ServerEvent)
- or -
Dim args As ClientEvent = CType(EventArgs, ClientEvent)Remarks
The server assigns each connected peer a unique ID, this is done to have a fixed reference to a specific connection.
All operations are multi threading, direct Event to GUI operations have to be made cross thread save.
Example for a file transfer from server to client:
Code
Me.Server.SendFile(args.Client,"..\somepath\file.ext",<optional transfer ID>)And from the client side to receive:
Code
Dim args As ClientEvent = CType(EventArgs, ClientEvent)
If (args.Packet.ContentType = ContentType.File) then
args.GetAttachement.SaveAs("..\somepath\" & handler.GetAttachement.Filename)
End IfSending objects across the pipeline
Code
Me.Server.Send(handler.Client, ContentType.SerializedData, "Welcome!")
Me.Server.Send(handler.Client, ContentType.SerializedData, true)
Me.Server.Send(handler.Client, ContentType.SerializedData, Math.PI)
Me.Server.Send(handler.Client, ContentType.SerializedData, New Byte(){})We can basically send anything we want but there is a catch to this concept, if we decide to send a custom object,
it be a structure or class it HAS to be a known reference type for both sides. Thats why i use this Protocol as middle man.
Define you custom objects in there which is then released with the client itself.
Remarks
Transfer of files have a so called ID (As Object) which is used to identify this file for a certain reason, it can be number or string , etc,
as long as this ID object can be serialized everything is fine.
Send content flags explained
Code
Public Enum ContentType As Byte
Synchronize = 2
Acknowledge = 4
Handshake = 6
SerializedData = 8
File = 10
End EnumThe first three flags are only used for the protocol to identify itself to another, not used for our purpose.
Safety
The server has a minimal protection, it does not use encryption however this is easily achieved since we (you) control the payload, all what the Framework does is sending it over a controlled connection.
It does contain some minimal safety features such as a maximum buffer overflow limit and protocol version vertification.
If any client, it be new or accepted, over steps these limits, the server drops the connection immediately, if a packet
is not the way it should (think of checksum or not able to construct the packet) it will drop the received data.
(Default values, 5mb max per payload and protocol version is changeable in the config)
Lag and Latency
The server maintains a threshold latency, if a client is too slow or simply not responsive it will drop the connection.
(Default value i use is 30 seconds)
Final notes
I include the demo app that demonstrates how to use it, if you got a question post them.
If you don't understand the workings of TCP connections, im not trying to be rude, but i am not going to explain that.
I assume you know how this works and i give you this source to extend your effort with your goal in whatever project you are developing.
Source:
- Version: A2 https://dl.dropboxusercontent.com/u/8007...a2.src.zip
- Version: A1 removed
Those that see in the right place, know. Keep that in mind :)
