Develop Reference

Capture and edit TCP/UDP packets in C#

I'm trying to create a tool, which would append/edit something inside specific packets, before they get sent to the specific website.
For now I was using Wpe Pro to apply this filter.
Is there something similar in C# to create this tool?

There is not really a general way to do this. There are multiple possibilities you have to consider and see if they fit your situation. For example you can edit a packet that is send using HTTP by using Pcap.NET (as said in the comments) easily. There are dozens of examples out there on the web that will guide you in modifying packets using Pcap, for example this discussion on the official Pcap.NET forums.
However, if the packet is using HTTPS (SSL/TLS) then the payload, which is the actual data being send, will be encrypted and this could be bypassed; if one/multiple precondition(s) of SSL are broken or by using a tool like sslstrip (python). Note that sslstrip will try to force the socket to be send through HTTP even if HTTPS is requested and this is not guaranteed to work.
Personally I will always try to avoid touching the sockets even anything network related. Especially when it involves HTTPS, because as you probably understand by now, this is pretty hard to bypass. I have no idea what program you are attempting to break, but I felt like it would benefit to this answer.
For HTTP, one could easily create a simple program that hooks the Windows Socket API. You should be looking into the send function and possibly even the recv (receive) function. You can modify the payload as you wish or even replace it with another payload, if desired.
Note that data that is send through the winsock.send function is already encrypted (if SSL/TLS is being used) as the application will handle layers 7 (application layer), 6 (presentation layer) and 5 (session layer, this is where SSL gets applied) of the OSI model. Winsock is a bridge between layer 5 and 4.
For HTTPS you can still use hooking, but you must hook the part of the application where it handles the connections and make sure you apply your (modified) payload before it initializes the connection / sets the payload. This may sound hard to do, put it is actually pretty easy to do, if you are willing to learn and have some time.

Server Console/Service APP <-> WPF Client communication framework sought

I am looking for an open-source framework that can handle communication between my backend host and a WPF frontend client. The following are points I need to consider:
Client is a WPF desktop app, host is a C# console APP but can also run as Windows Service
Host can accept connection requests, client connects, but I still seek bi-direction communication capabilities.
The client and host are not in the same network (need to send messages over the internet)
Just one (possibly more but less than 10) client will connect to the host.
I like to be able to handle the following communication patterns: One-way message, two-way request/response, and streaming from host to client.
The content will consist of serialized POCOs/DTOs and serialized time series data. Each serialized DTO will be of approximately size 400 bytes, the serialized time series can be a lot larger, potentially several megabytes.
Some messages will be sent scheduled, meaning for example, the host sends a new DTO every second. (if the framework includes such scheduling mechanism then even better)
I like to be able to stream data to the client, such as a client that receives and then updates data on its GUI in real-time.
My question is: What might be the best C# based framework to handle this? (I run on .Net 4.5) I do not consider WCF because it seems way too thick and complex for what I try to handle. I also do not want to delve into web programming, so Rest/Soap type frameworks are not under consideration. I would be delighted if anyone could recommend a tcp/websocket based framework or similar that is light weight enough to potentially send messages a lot more frequently than just every second.
Thanks a lot in advance.

Any reason why you are not considering HTTP? It is just over TCP but you don't need to worry about firewalls and stuff, especially given the fact that you want to do this over internet. Self-hosted ASP.NET Web API can be a good candidate. Fire and forget and request/response can be accomplished fairly straight forward and for streaming it has PushStreamContent. ASP.NET Web API is light weight compared to WCF and is open source. Just a suggestion, that's all.

I ended up using ZeroMQ for full-duplex communication between WPF client and Server. It is lightweight, very fast and pretty reliable for my needs.

Options to stack native protocol over http?

We have a client/server system where all communications are done using a native protocol over a binary/SSL stream on TCP. All of our code is written in C# .NET 2.0 and some parts in 3.5. Our protocol is designed to support a variety of messaging patterns, namely Request/Response, and for lack of a better term, one-way messages from either the client or the server on an irregular basis.
Our objective is to add a feature to our system to carry our protocol over HTTP. There are several reasons for doing so, but I don't need to explain that here I think. Please tell me if I should.
The thought is to embed our protocol as application/binary in HTTP requests using the standard request methods ie., GET, PUT, POST, but not DELETE, and following the HTTP specification. This would be rather straight forward to do if our protocol was only request/response. The main concern comes from the one-way messages, and more specifically the unsolicited messages coming from the server. Another important concern is that HTTP is not oriented for persistent connections, but I believe with HTTP/1.1 this can be overcome. A third concern is that the server connections are not stateless.
We've been designing and prototyping this for a couple weeks, and we've come up with a couple ideas:
Refactor the code in the communication and protocol layers on both server and client sides. Although much of the code is shared, it is a lot of work that in all likely hood will not be a success. The question here is can this even be done with our poorly designed protocol?
Use a proxy approach. That is create an HTTP server using WCF and unwrap the HTTP messages and relay the native messages to and from our server over persistent connections. This would require a layer of abstraction on the client side that would actually maintain two connections to the proxy. One connection to perform request/response and the other to carry the unsolicited messages using a delayed response technique.
HTTP Tunneling which we haven't yet researched.
We're hoping that someone has encountered this challenge before and could lend some sound advice?
Please accept my apologies if this is the wrong place to post this question.

For the server initiated messages, you might consider WebSockets. According to Scott Guthrie's blog there is support for web sockets in ASP.Net MVC 4 beta.

C#: Question about socket programming (sync or async)

I'm writing an instant messaging server in C# for learning purposes.
My question is whether I should use synchronous or asynchronous sockets to handle the IM clients. The goal is to handle as many clients as possible.
I'm not quite sure but as far as I know with async sockets the packets don't arrive in order which means when you send 2 chat messages and there is a delay/lag it's possible that the second one arrive before the first one. Is this right and if so, is there a way to solve this issue?
About sync sockets: Is synchronous sockets a good solution for many clients? Do I have to check every socket/connection in a loop if there are new packets? If so, isn't this quite slow?
Last question: Assume I want to implement a way to send files (e.g. images) through the protocol (which is a non-standard binary protocol btw), can I still send messages while uploading?

The goal is to handle as many clients as possible.
Async then. It scales a lot better.
I'm not quite sure but as far as I know with async sockets the packets don't arrive in order which means when you send 2 chat messages and there is a delay/lag it's possible that the second one arrive before the first one.
TCP guarantees that everything arrives in order.
Assume I want to implement a way to send files (e.g. images) through the protocol (which is a non-standard binary protocol btw), can I still send messages while uploading
I recommend that you use a separate connection for file transfers. Use the first connection to do a handshake (determine which port to use and specify file name etc). Then use Socket.SendFile on the new socket to transfer the file.

Everything #jgauffin said (i.e. TCP handles packet-order, async better for n(clients) > 1000).
Assume I want to implement a way to send files (e.g. images) through the protocol (which is a non-standard binary protocol btw), can I still send messages while uploading?
Your custom protocol has to be built to support this. If you write a 8MB packet to the Socket, you won't be able to write anything else using that socket until the 8MB are sent. Instead, use upload-chunks of smaller size so that other packets have the chance to go over the pipe as well.
[UPLOAD id=123 START length=8012389]
[UPLOAD id=123 PART chunk=1 length=2048 data=...]
[UPLOAD id=123 PART chunk=2 length=2048 data=...]
[MESSAGE to="foo#example.com" text="Hi"]
[UPLOAD id=123 PART chunk=3 length=2048 data=...]
// ...
[UPLOAD id=123 COMPLETE checksum=0xdeadbeef]

The difference between an async approach and a sync approach is more about the difference between non-blocking and blocking io. With both approaches, the data is delivered in the same order that it has been transmitted. However, you don't block while you wait for an async call to complete, so you can start transmitting to all of your clients, before any of the individual communications has finished writing to the socket (which is why typically it would be the approach followed by servers).
If you go down the sync route, you block until each transmission / receive operation has completed, which means you may require need to run multiple threads to handle the clients.
As far as uploading an image at the same time as sending messages, you may want to handle that down a different pipe connection between the client/server so that it doesn't cause a blockage.

Is out there any sample of reading http requests using TCP socket collecting data from them (like emulating Http server in some way)

Is out there any sample of reading http requests using TCP socket collecting data from them (like emulating Http server in some way) so I wanna to keep data like senders IP:PORT, request body and so on.
So has any one seen such thing in OpenSource projects or do you know how to create it? (if so please provide siple code example)

In retrospect, HTTP is not the easiest protocol to parse. If it were designed from scratch today, it would be very different.
First off, use ASP.NET if possible. If you can't use ASP.NET, then take a look at the HttpListener class.