I want to do a project, that will include server and clients sides, using TcpSocket network communication (I use TcpListener for server and TcpClient for client side) and threading. But threading is not giving me any problems so far any longer.
But what it does, is something else... because the project will not include only chat, (but also creating new game, joining game, making moves, leaving game), I need to define somehow the message format.
I have read about messaging protocols and about using first few bytes of each message to tell the server what they are trying to do. The problem is that I do NOT know how to do it. So can someone show me an example of creating formated message?
Maybe its good to mention I use StreamReader and StreamWriter classes to pass data between server and clients. Is this a good way?
To add:
My problem now, is how to seperate this data, so that the server will know what to do with it. I have read about using 1nd few bytes to "be reserved" for the type of the message. But the problem is I don't know how to solve this issue. So far I was only using StreamReader and StreamWriter classes to pass only strings. If I use these kind of coding, it will all become too messy (not recognizable), if you know what I mean.
So I need to do something like it:
To send bytes:
1st few bytes the type of the data (but I don't know which class to use, maybe a BinaryWriter, and BinaryReader on the other side??)
the rest of the message
on server I have to have some code that will recognize these "1st few bytes" so the code will know what to do with the test of the message.
and based on these "1st few bytes" the code has to send data back to clients
Do you have any ideas on what this might look like, I mean as a skeleton (something basic, so I can work on with it).
Every bit of help would be very much appreciated.
I have found one example here on stackOverflow.com. It seems to be a code into a right direction. What do you think guys?
One option that might be much easier than defining your own protocol would be to use some existing library, like WCF or JSON-RPC.
Libraries like this have their disadvantages (they often produce output that is relatively big). If if you build your applications in a modular way, you can easily switch the communication backend later, when you find your first solution wasn't good enough.
You have a few options:
Make the message format textual - including its header. So, the header contains the message size, written out as text string, and ends with some terminator (\r\n for example.) HTTP takes this approach - the headers are text. When receiving the message, you process it with ReadLine, and parse header lines with stuff like int.TryParse(str).
Send message:
output.WriteLine(message.Length);
output.Write(message);
Receive message:
int len = int.Parse(input.ReadLine());
//message is the next 'len' characters
A second option: entire message is in a binary format - the message header is binary, and specifies amongst other things the message length. Message content is written as a stream of bytes, encoded using for example Encoding.UTF8.GetBytes(str).
Or, perhaps use the HTTP protocol? I believe there is basic support for HTTP server in the form of HttpListener. Here is a simple intro to HttpListener
Whatever you do, avoid using WCF :)
Related
We create client-server erp system with huge amount(in the future) of data and use c# for client and c for server. We started with xml for small requests/responses and it looks ok for now. But what is the best data exchange format for increasing amount of data per response(up to 100MB i think)?
P.S.
Highest priority is encode/decode speed.
We use Sockets to transfer data.
It really depends on what kind of data you are going to send to and receive back from the server. If “data” is some sort of a buffer with the known length and the usual operations are to put / get an object to / from the server, then I would recommend you to take a look at HTTP: it's a very simple protocol, there are many libraries and applications that support it, you can easily extend the protocol, add an encryption (HTTPS) and compression (gzip), and this protocol is easy to debug and work with.
If you want to send network packets that contain many data fields of different types, then you want to encode and decode such packet (serialize) before sending to the network. There are a plenty of open source libraries in the Internet which support both C and C# languages (you can even write your own implementation, it's not that hard). I would recommend you to take a look at XML / JSON (text-based standards for data exchange), you will find it much more easier to debug communication problem when working with a textural data.
Hope it helps !
I would suggest to take a look at JSON:
http://www.json.org/
To do some WCF benchmarking, I need to have a way to get the size of the exchanged data(with all header(even TCP)/compression/...).
It's in a bigger benchmarking(which also tries different binding, encoding, ...) so I need to do it programmatically and NOT through something like wireshark.
Is there a hook somewhere to do this?
All channels/bindings/encoders are created programmatically to automate some tests.
I found some ways( http://devlicio.us/blogs/derik_whittaker/archive/2011/02/03/how-to-intercept-a-wcf-message-to-track-message-size.aspx ), but I'm not sure it will work with non-text data. Or http://zamd.net/2008/08/15/calculating-wcf-message-size/ but I don't see how to start it(and not sure it will works with my custom encoders
Write a MessageInspector. This will give you an event for all messages.
http://msdn.microsoft.com/en-us/library/system.servicemodel.dispatcher.clientruntime.messageinspectors.aspx
You might be able to use WMI performance counters
http://msdn.microsoft.com/en-us/library/ms735098.aspx
You have 2 options:
use WCF extensibility. this will typically be more work, and you will need to consider various wcf situations.
use out of band solution like wireshark
I'm not sure why you prefer the former - I recommend to try wireshark, I'm sure it can be automated too. Anyway if you want to do this inside wcf you should implement a custom message encoder to calaulate the size of bytes that go on the wire. this would need to be a generic encoder that wraps any other encoder inside it. here is an example for a generic encoder.
note that the encoder approach will only consider the message size, but not any framing on top of it (HTTP headers for example). This is why I think wireshark is better for your case.
I've just made a quick research about that but there is nothing about that in C#.
Is this a lost cause or it can be made?
As Yahoo Messenger is not an open source project, I have no idea about how sending message is implemented. First thing you should do is launching Wireshark on your machine to see how Yahoo Messenger works (which port is used, which protocol, data encryption...etc.).
When you have determined how the application works, you'll have to write some low level code that intercepts and modifies the bytes Yahoo Messenger sends. You'll probably have to write a driver, so it looks to me like a dead-end if your are using C#. And even using C/C++ or any langage usable to write drivers, it'll require a large amount of time/resources IMO.
You are trying to modify behavior of an closed source application. The only thing i can think of is somehow goeing lower-level in the OSI model (Transport layer i.e.) and change values. This sounds like a bad idea.
Actually i even wonder whether that data is sent plain-text or that encryption etc. has been used. I wonder if you can actually change the message at all.
I am thinking of making a server/client application that does this: the client(s) will connect to the server and the server will send back a list of folders (probably music or videos) that the client will be able to stream or download. I am going to make a GUI for this so that it won't be a text-only interface. I want it so that when the client connects to the server and gets the information about the media files that can be streamed/downloaded, the client will show the folders/files in an explorer-like interface (folders will show up with a folder icon, videos will show up with a video icon, etc.)
This seems really big to me but I really want to learn more about socket programming with C# and feel that getting my hands really dirty is the best way. As you can imagine, I have a lot of confusion about how to start this and what it is that I need to do to make this work.
The first part of my question is: If I want to let a client receive a list of files/folders and also have the ability to download/stream them, do I need to do something with transferring binary data using sockets or am I completely wrong on that? If I'm wrong, do I need to use something else like file readers and somehow use them over sockets?
The second part to my question is: when I transfer this information over to a client, how can I make the client show the appropriate icons for videos, folders, mp3s, etc.? I'm thinking that if I have to transfer binary data I will have to use that data to somehow populate the client GUI with the correct icons/data. I am stuck on exactly how to handle that. Are there certain methods/classes that I can use to parse that data and do what I want to do with it? Again, I don't know if I'm wrong about needing to transfer binary data but either way I am confused on what it is that's necessary to handle this.
I apologize if any of my terminology is wrong. I am obviously not an expert in C# yet ;)
Any time you are sending data between machines (or between processes), you are already talking binary data (you could argue that everything is binary data, but when working with it as an OO model it doesn't feel like it). The point here is that all you need to do is serialize your messages. There are a myriad of serialization frameworks - some aimed at convenience, some aimed to range-of-features, and som can use aimed at performance (minimum bandwidth etc).
Even the inbuilt ones would work - for example, you can use XmlSerializer etc to write to a Stream (such as the NetworkStream you typically use with a socket). But please - not BinaryFormatter (it will hurt you, honest). Personally I'd use something a bit less verbose such as protobuf-net, but I'm somewhat biased since I wrote it ;p
However, note that when working with sockets, you are typically sending multiple (separate) messages as part of the conversation. In order for each end to correctly and conveniently read the right data per-message from the stream, it is common to prefix each message with the length (number of bytes) - for example, as a little-endian int taking a fixed 4 bytes. So the reading process is:
read 4 bytes
interpret that as an int, let's say n
read n bytes
run that data through your deserializer, perhaps via MemoryStream
process the message
and the sending process might be:
serialize the message, perhaps to a MemoryStream
query the length and form the 4 byte prefix
write the prefix
write the data
You don't have to go to as low level as Socket, unless you just want to learn of course.
I suggest using WCF. It will completely meet your requirements, will be flexible and you will not have to deal with sockets directly.
WCF is a big framework, but you can quickly learn how to use it.
Introduction to WCF
Here you can find how to retrieve and show file icon in Windows.
If you client is hosted by Windows, you don't need to transfer icons, you can just retrieve image on the client by filename/extension.
I have read somewhere that I better use multi-part types on receive and send ports, but can't understand one thing. If I receive some XML data through say HTTP port how do I put it in right path in the message. Should I create custom pipeline for this or there is something else (I'm new to BizTalk)?
Sergej,
You must have picked up this concept half baked from the article 8 Tips and Tricks for BizTalk Programming (http://msdn.microsoft.com/en-us/magazine/cc163423.aspx)
As explained in the article, it makes more sense to create Multi-Part messages inside the orchestrations, so when you want to change something in the schema its easy to do so without deleting all the links between the ports and send/receive shapes.
Assigning a message to a specific part (normally the first part) should not be a big issue within the orchestration, you should be able to do it via maps or within the message assignment shape.
HTH
There's really no hard and fast rule about using multi-part message types for something like this; it really depends a lot on your scenario.
However, I'd like to point out that, underneath, all messages in BizTalk are, at the lowest level, multi-part messages. The question is whether accessing those extra parts (if they are present) is easy in an orchestration or not ;)
That said, let me point out that, in many cases, there's little reason to use multi-part message types in orchestrations. For example, the HTTP or FILE adapters will never generate a message with multiple parts on their own, unless perhaps you've got something like the SMIME decoding component on your receive pipeline.
Some other adapters do definitely take advantage of multi-part message types, like perhaps the POP adapter (attachments) or the SOAP adapter. But unless you've got an scenario like this, that really requires multi-part message types, I see little reason why you'd start with those.