I am working on an application that needs to control another device.
This control should be using Wi-Fi.
How can this be done in C#?
Important to know that the other device I want to make it.
I can afford the part of making and design but how to make it connect to PC using Wi-Fi?
I don't know about it.
I just need a key to start searching or some thing similar.
Connecting over Wi-Fi could be as easy as opening a socket on the server, and another on the client, and start streaming data. Of course this if both devices are compatible and has Wi-Fi receivers. Just think of them as two computers connected with a wire, or without a wire they will just behave the same.
The connection protocol will care about doing the magic of converting what you write on the socket, into RF signals received from the other device and converted back to bytes.
But if you are building your own antenna/receiver/protocol ... then things will be much more complicated.
If you have to ask then you're probably going to want a single board computer. Popular choices are:
gumstix
Zii EGG
nwg100 by Atmel
(XBee) --not too sure about these, I haven't used.
You can install a network stack and everything on them.
Related
Can you tell me please how can I establish/tear down an existing ethernet (LAN) connection using C#?
In Windows UI it's quite simple, you're clicking right mouse button on the connection and choosing "Connect"/"Disconnect" command from the context menu. Is there any programmatic analogue of that action? It seemed rather simple to me but eventually I've found nothing on this matter. I found how to check a connection status, how to enumerate all the network interfaces, how to dial a 3G modem connection, how to enable/disable a network card, how to monitor availability of the net, etc, anything but this! Generally I need a software switcher that will be able to turn on and off an ethernet connection (not a network card!).
Isn't there a simple method something like GetConnection(connectionName).Connect()?
Make some searches on TCP/IP Client/Server modeling in c#, you actually can start by some already existing sample codes like this
Ethernet doesn't have a concept of "connected" or "disconnected". It is really a multiple random access medium. Also, I'm not sure what UI element you are talking about. On my machine, I can "connect/disconnect" wireless adapters, but not Ethernet adapters. This is because most wireless protocols have an actual concept of being "connected" to some access point. If you are really talking about a wireless adapter, I'm sure there are windows API's that can control them, but I don't know off hand where to point you. Otherwise, I think you might need to take a step back and explain the larger context of what you want to accomplish.
I'm writing an network related application and I want to protect it from reverse engineering by shutting it down, if packet sniffer is detected. How can I detect if packet sniffer is running? I could check the running apps and check their names against pre-defined strings (wireshark, httpanalyzer, etc..), but that doesn't seem to be the best way to do it. Is there a way to determinate if application is sniffing packets? Thanks
There is fundamentally no way to do this in general. Most networks in use today are intended to send the packets across the network in a manner that permits (or even requires) all devices on the cable to see the packets.
You have to get over the concept that your work is so valuable that you need to protect it in this way (or by using copy protection, obfuscation, etc). Protect your application by producing a great application that everyone will want to actually pay for.
You know you can run the sniffer on the router using openwrt and there is no way you could detect that.Just encrypt the stream.
I have been reading up on the web and cannot find any information on working with a RS485 MultiDrop connection in c#
To give a bit of insight. I have written an application to communicate with a Serial device using the MODBUS RTU protocol. Now the client has informed me there devices may be hooked up using multidrop communications links. Being a novice when it comes to working with serial devices I am a bit lost here.
My question is simply: Where do I start? a Google search has thus far only produced hardware converters and wikipedia entries for different Serial Communication standards.
Thanks!
RS485 is a standard that defines the electrical characteristics of a particular multi-drop networking arrangement. I once used it as the internal bus for an instrument - the main control board drove various pumps which were arranged on an RS485 network.
You can get half-duplex and full duplex arrangements (half means that one device can talk at a time - full means send and receive can happen at the same time).
Really using it is not a whole lot different from using an RS232 or serial port, and as you've seen you can get serial to RS485 converters. You can use the serial port drivers in C# to use it.
SerialPort Class
Your main problem is that RS485 doesn't really address how it should be used - its a fairly low level electrical spec, it doesn't define how you should use it to make communication happen.
The main issue you need to consider is how you're going to coordinate all this. With RS232 - there are two things connected, which makes it easy - usually a computer and some device. With RS485, there are many things connected. So you need some way of addressing each device. You don't give any details about the 'device' referred to here - but if they are intended to be connected on RS485 - then there will be a way of addressing them. There are however several ways this could work - so I can't help you on specifics without more detail. With the system I developed, all communication was initiated by the 'master' device (i.e. my control board - or your c# application for example) and each message sent had the receiver's address on it - so the right pump knew that the instruction was intended for it.
I hope this is of some help. Really its not that complicated, but you need to think about what these devices do, how they are addressed, and think about the messages that you need to send back and forth. You can use the C# SerialPort classes to actually do the work.
The book referred to in the other answer looks great by the way. I really would consider buying it if this is all new to you. It covers serial port communications, and has a chapter on RS485.
I have not worked with RS485 but this book can be a help in understanding Serial port and USBs.
here is another link which discuss specs and here is another. I dont think they will be readily implemented in C# but could be.
Here's the scenario - I have a C# application that reads from a COM port. Most of the time I use devices with a serial adapter and on a machine with a serial ports. However, machines with serial ports are increasingly difficult to come by so I have started using machines with a USB/Serial connection.
In some cases, the C# code that I have will work just fine with a "true" serial connection but fail with a USB/serial connection. The data comes in fragmented with the first part of the data coming in (like maybe the first 1 or 2 characters) and nothing else.
I'm using something basic like comport.ReadExisting() to pick up the data from the port. Is this part of the problem? Are there other methods that would guarantee that all the data would be read in a single string?
Finally, I want to add that I've already played around with some of the USB/serial settings in device manager AND the data comes in fine when using good, ole' hyperterminal . . . so it has to be something in the code.
With USB-serial converters, you MUST set your receive timeout, because the data can sit in the USB device for a long time where Windows doesn't know about it. Real serial ports hold data in the 16550 FIFO where the Windows driver can see it.
Most of the times you would want to use the SerialPort.DataReceived event ( http://msdn.microsoft.com/en-us/library/system.io.ports.serialport.datareceived.aspx ).
This requires you to combine the chunks of data manually since you can receive parts of your string, but once you detect the boundary of a single 'record' you can fire of processing that record while letting the IO receive more events.
This allows some asynchronous IO which doesn't block your threads, and thus allows more efficient handling of the data in general. If it helps in your specific situation I don't know, but it has helped me in the past dealing with data reading issues, low speeds, thread pooling, and lock-ups.
I'm thinking like the methods games like Counter Sstrike, WoW etc uses. In CS you often have just like 50 ping, is there any way to send information to an online MySQL database at that speed?
Currently I'm using an online PHP script which my program requests, but this is really slow, because the program first has to send headers and post-information to it, and then retrieve the result as an ordinary webpage.
There really have to be any easier, faster way of doing this? I've heard about TCP/IP, is this what I should use here? Is it possible for it to connect to the database in a faster way than indirectly via the PHP script?
TCP/IP is made up of three protocols:
TCP
UDP
ICMP
ICMP is what you are using when you ping another computer on a network.
Games, like CounterStrike, don't care about what you previously did. So there's no requirement for completeness, to be able to reconstruct what you did (which is why competitors have to tape what they are doing). This is what UDP is used for - there's no guarantee that data is delivered or received. Which is why lag can be such a problem - you're already dead, you just didn't know it.
TCP guarantees that data is sent and received. Slower than UDP.
There are numerous things to be aware of to have a fast connection - less hops, etc.
Client-to-server for latency-critical stuff? Use non-blocking UDP.
For reliable stuff that can be a little slower, if you use TCP make sure you do so in a non-blocking fashion (select(), non-blocking send, etc.).
The big reason to use UDP is if you have time-sensitive data - if the position of a critter gets dropped, you're better off ignoring it and sending the next position packet rather than re-sending the last one.
And I don't think any high-performance game has each and every call resolve to a call to the database. It's more common to (if a database is even used) persist data occasionally, or at important events.
You're not going to implement Counterstrike or anything similar on top of http.
Most games like the ones you cite use UDP for this (one of the TCP/IP suite of protocols.) UDP is chosen over TCP for this application since it's lighter weight allowing for better performance and TCP's reliability features aren't necessary.
Keep in mind though, those games have standalone clients and servers usually written in C or C++. If your application is browser-based and you're trying to do this over HTTP then use a long-lived connection and strip back the headers as much as possible, including cookies. The Tornado framework may be of interest to you there. You may also want to look into HTML5 WebSockets however widespread support is still a fair way off.
If you are targeting a browser-based plugin like Flash, Java, SilverLight then you may be able to use UDP but I don't know enough about those platforms to confirm.
Edit:
Also worth mentioning: once your networking code and protocol is sufficiently optimized there are still things you can do to improve the experience for players with high pings.