How can I catch TCP SYNC events for particular socket in .NET?
I want to be able to fire off a method which will detect if request for SFTP data transfer is made and on completion to do some action like notification or logging.
Presuming that the socket you want to detect the open and close of is not one your program is responsible for itself, but some other process on the system is handling it, the best way may be to use the winpcap library. winpcap allows you to subscribe to a raw feed of all IP packets coming into and going out of your network interfaces. You c an also provide a filter such as "Only show me TCP packets on port 22". Your program receives the raw packets so you get the ethernet header, followed by the IP header, followed by the TCP header, followed by the data payload (payload will be encrypted for SFTP). Analyising these packets you will be able to detect the TCP handshake on connect and know the IP and port that is connecting and detect when the TCP steam is closed.
I don't use .NET myself, but I did find this winpcap wrapper for .NET on Google which should allow you to use winpcap from your .NET application.
WinPCAP.NET Wrapper
Related
I have a windows form App which is written to send and recieve texts, this is implemented by sending a message via .NET Remoting to a Service installed on a server, which has a GSM modem (dongle) connected to it, the service then sends the message through the GSM modem once it has a message from the Client App.
Everything's going well so far with regards to sending a text, However we need functionality to enable the reading of incoming text messages; I'm unsure how to go about writing my code to listen out for incoming texts, and then send them over to my Client App.
Could anyone give me some pointers on where to start please? I've tried MSDN Documentation on the TcpClientChannel Classes, but this doesn't prove useful for listening to the COM port or anything like that.
If you are using the AT command set then I'm afraid your server will have to poll the dongle's SIM for messages at an interval (whatever makes sense).
In terms or notifying the client you can either:
follow the same scheme as the server and poll regularly
-or-
if the remoting connection is open continuously, have the server notify using an event on one of your remoting objects. The event args for this event can contain all of the new messages.
Is there a way to intercept TCP and UDP traffic that is inside localhost on Windows in C#? For example an app running on localhost sending messages through TCP and/or UDP on localhost... I need to intercept these to determine the efficiency of data of the program, for this I'm building an utility tool in C# (need a self build solution no product)
Usually you have to use program like wireshark to capture loopback (127.0.0.1) traffic, but it's impossible for libpcap on Windows. (read this note)
You have to use Raw Cap if you want to sniff the loopback interface
I am creating a program which can send test or data to Bluetooth devices. For this purpose I want to use the virtual serial ports supplied by Bluetooth software.
Q. Is there is any way to send network stream to virtual serial port like socket programming in LAN?
Q. How do I receive data form Bluetooth? Does it is in the form of Network Stream?
Q. Which is the fast method to send and receive data over Bluetooth?
Because I not only send text to the device but also Images and other type of data.
1) Not certain about Bluetooth virtual ports, but I suspect that you can just use readFile/writeFile, (or the 'Ex' asynchronous versions), to the handle returned by CreateFile(), just like a 'normal' serial port. If so, you can handle the handle, (sorry!), just like the socket handle raised in a client socket connect() or a server listener accept(). So you should be able to use a dedicated thread, an I/Ocompletion routine, or IO completion ports to communicate with the virtual port.
I have done something like this before, but with Delphi and a 'real' serial port and a client network connection. I used an IO completion routine where an 'IOhandler' class was transferred to the completion routine in the 'hEvent' field. The serial port and client socket classes were IOhandler descendants, so the same IO completion routine code worked for both. It worked OK, (eventually:). I don't know of any reason why it would not work OK in C#.
2) Again, certain about Bluetooth virtual ports. Given that many Bluetooth implementations can supply these virtual COM ports as an interface, then the transport must surely be an 'octet stream', just like TCP or a 'real' COM port.
3) On Windows? I suspect IO completion ports. Probably dosn't matter much because Bluetooth bandwidth is not that great compared with what Windows can handle.
Rgds,
Martin
might this will help you
mCore™ .NET SMS Library
After sending some tcp data with the blocking/non-blocking methods such as:
Socket.Send() or Socket.SendAsync()
How can I know that my data has received an ACK message?
Can .NET know if TCP data has been successfully sent?
The only way to know for sure is to implement some kind of application-level acknowledgement. The TCP level "ACK" packet is not exposed to the application level at all, so you have to use something more than that.
You make the other end respond to it.
Even if TCP has Acked it, if the receiving end terminates (for good or bad reasons) before processing the message and acting on it, you still don't know, so the only way to know is for the other end to tell you.
This information isn't available from .net's class libraries. I had the same kind of considerations when I started working on this port scanner in C#. I have made use of a .NET wrapper for libpcap (after installing the corresponding driver), the SharpPcap (http://sourceforge.net/projects/sharppcap/), in order to get this kind of information. The ACK packets are obtained through SharpPcap's interface (invoking the native libpcap interface's transparently).
My application is NScanner Port Scanner/Sweeper and you can find the code at codeplex, referencing to you my simple usage of the aforementioned library (http://nscanner.codeplex.com/).
I hope I helped.
"I'm trying to focus on how can you know when your data has been accepted by the other-side of the connection."
I think you need to be aware what type of application layer protocol you are going to implement and what impact this has on application performance.
Take HTTP as an example of a "Streaming like" protocol. A server posts a stream of data to a client. There are no more additional application layer "ACKs" and the server doesn't actually care when and how exactly his stream of data arrives. This is very efficent on high latency links.
Now compare this to SMB! Instead of streaming a file, data is partitioned into blocks. Every successfully transferred block of data is acked on the application layer. This gives you more control, however, it effectively kills the protocol on WAN networks (check out "Bandwidth Delay Product").
Taking this into consideration, you can come up with your own design for your custom protocol.
The TCP layer will keep resending the packet until it receives a successful ACK.
Send will block until this happens - SendAsync will not block, and you can continue processing other stuff while the TCP layer handles sending the packet.
I recommend using Pcap.Net.
You can easily sniff packets using this library in C# and then easily check the packet values.
You can also easily build and send packets.
If you are really certain that you need to know the packet level details of your TCP connection, then in addition to creating the TCP socket for sending, you need your application to use the winpcap API to look at the raw traffic as well. You can install a filter to only receive packets relevant to the particular IP,port combination that determines your remote side.
There are a couple of projects out there creating .NET wrappers for libpcap, for example here
I have a client-server app where the client is on a Windows Mobile 6 device, written in C++ and the server is on full Windows and written in C#.
Originally, I only needed it to send messages from the client to the server, with the server only ever sending back an acknowledgement that it received the message. Now, I would like to update it so that the server can actually send a message to the client to request data. As I currently have it set up so the client is only in receive mode after it sends data to the server, this doesn't allow for the server to send a request at any time. I would have to wait for client data. My first thought would be to create another thread on the client with a separate open socket, listening for server requests...just like the server already has in respect the client. Is there a way, within the same thread and using the same socket, to all the server to send requests at any time?
Can you use something to the effect of WaitForMultipleObjects() and pass it a receive buffer and an event that tells it there is data to be sent?
When I needed to write an application with a client-server model where the clients could leave and enter whenever they want, (I assume that's also the case for your application as you use mobile devices) I made sure that the clients send an online message to the server, indicating they were connected and ready to do whatever they needed doing.
at that time the server could send messages back to the client trough the same open connection.
Also, but I don't know if that is applicable for you, I had some sort of heartbeat the clients sent to the server, letting it know it was still online. That way the server knows when a client was forcibly disconnected from the network and it could mark that client back as offline.
Using asynchronous communication is totally possible in single thread!
There is a common design pattern in network software development called the reactor pattern (look at this book). Some well known network library provides an implementation of this pattern (look at ACE).
Briefly, the reactor is an object, you register all your sockets inside, and you wait for something. If something happened (new data arrived, connection close...) the reactor will notify you. And of course, you can use only one socket to send and received data asynchronously.
I'm not clear on whether or not you're wanting to add the asynchronous bits to the server in C# or the client in C++.
If you're talking about doing this in C++, desktop Windows platforms can do socket I/O asynchronously through the API's that use overlapped I/O. For sockets, WSASend, WSARecv both allow async I/O (read the documentation on their LPOVERLAPPED parameters, which you can populate with events that get set when the I/O completes).
I don't know if Windows Mobile platforms support these functions, so you might have to do some additional digging.
Check out asio. It is a cross compatable c++ library for asyncronous IO. I am not sure if this would be useful for the server ( I have never tried to link a standard c++ DLL to a c# project) but for the client it would be useful.
We use it with our application, and it solved most of our IO concurrency problems.