I need to configure the baud rate of the ethernet port of my pc as 100Mbps. But after searching the net, I couldn't find a way to change the baud rate in the socket in C# code. Is it possible to set the baud rate for the Ethernet port in C#.
I actually need to communicate between pc and a micro controller. So if, in the micro controller, the baud rate of the Ethernet port is set to 100Mbps, then will the baud rate of the Ethernet port in PC be also set to 100Mbps automatically?
Thank You
I think you've got terms and technologies mixed up a bit. It sounds like you're used to working with serial connections (like RS232 or RS422) where both end-points have to be configured in the same manner.
IP networks don't operate that way. On a fairly modern switch, each connected device can have it's own link speed. So the computer can be connected with 1GBps and another computer can have 100MBit, all dependent on what that computers interface can handle.
The network protocol you use should then handle throttling, resending of lost packets and such (like TCP does). If you use UDP you'll have to either not care about lost packets, or implement such mechanisms on your own.
If you connect your computer directly to the micro controller, then yes - the port speed of the computer is probably going to be 100MBit as well. But there is no guarantee. And even if there was, how would you know that the micro controller would actually be able to handle all data sent to it at that maximum theoretical speed?
Related
Does anyone know how do I check if a device is connected to a serial port? I need a sort of ping functionality so that I can ping the device and attempt to connect to it only if the ping succeeds. For instance if I don't have the COM cable plugged in, I can display the connection failed message much faster.
It just isn't quite the same problem as having to use Ping to find if a server that's located a thousand miles away is online. With serial ports you just look at the other end of the cable, you rarely have to walk more than a few feet.
There's also nothing similar to having a stateful connection like TCP. All you can really do is look at the hardware handshake signals. The SerialPort.DsrHolding gives you the state of the Data Set Ready signal. A properly implemented serial device uses that signal to say that it is powered-on. CtsHolding is an additional signal, it says that it is ready for you to send data. They normally have to be both turned on before you consider sending anything.
These handshake signals are not always properly implemented. You may well have a problem if the serial port is actually emulated by a BlueTooth or USB device driver for example. Pretty common these days with very little consistency in how closely these drivers emulate a real serial port. You'll have to try.
What is the data actual path if I run 2 applications sending/receiving data using sockets through TCP loopback? Will this data go through Windows network driver and/or NIC hardware?
EDIT. Please consider this is not Windows 'loopback' but physical loopback made on the NIC with 2 ports connected with a cable to each other making it physical loopback.
Loopback is a virtual interface, there's no hardware corresponding to it. Data copy happens inside the kernel even above the driver level.
Edit 0:
You are mixing two different things - loopback in TCP/IP is a virtual network interface with a special address in subnet 127/8, usually 127.0.0.1, which is created for you by default, and ethernet crossover cable looping between two cards on the same machine.
I addressed the first case in my initial answer.
The behavior of the TCP/IP stack in the second case depends on the implementation and the transport options. For a TCP connection and for unicast UDP the kernel might just realize that both source and target addresses are local to the machine and short-circuit data transfer through memory. You'll find that most modern network stacks behave this way. For broadcast or multicast UDP there's no other option but to send packets through physical card since there might be other listeners on the network.
I'm developing a wake up on LAN project but that I want to control if computer is open or not on my local area network. But I don't want to use ICMP or WMI (there are DCs on my network). So is there any other options for this problem like Socket Connection, check specific ports are using or not like this?
What's wrong with ICMP?
Anyway, you try accessing a port and measuring how long it takes for the connection to fail. If it fails quickly (You'll have to measure what 'quickly' is on your system), the computer is probably up and refusing connections. If it fails after a long time (again, measure to find out what 'long' is), the computer is probably down.
I doubt you'll be able to achieve 100% accuracy this way.
As you probably know, "Wake on LAN" is just a UDP broadcast on port 60000, with the packet containing the MAC address of the host you wish to activate:
UDP 255.255.255.0:60000
Soooooo ....
What good is "ping" (or anything else?) going to do if the host is "off"?
All you're really interested in is:
1) Can the host(s) in question receive your UDP broadcasts?
2) Is there anything between you and the host(s) blocking the port?
this is my first question here, after searching and reading through many places I have not choice but to ask.
I have a C# application that receives data from a GPS device and stored in a database, I need now is to send a string that contains commands which the device should be interpreted.
This device connects to the Internet over GPRS, I haven't idea how to send this packet over TCP over GPRS because the IP is dynamic.
I hope any suggestions or ideas on how to solve this.
Best regards.
You should do it the other way around - the device should poll the server for instructions. Just make sure the server is accessible.
As you have specified that you have developed a C# application to read the GPS data through GPRS that means you are running C# application on a public/static IP.
Nwo as soon as you get a request from the GPRS client, you get the DHCP IP address of the remote endpoint too.
Once you have that endpoint and socket open, you can transmit any data to the GPS device back.
Assuming that your GPS device is having some microcontroller to drive the GSM/GPRS modem.
I'm going to make an assumption here that the 'Device' is some kind of mobile phone connected to a standard GSM network?
If it is, then the short version of the story is "Forget it" even if the IP wasn't dynamic, you simply wouldn't be talking to the IP of your device, you'd actually be talking to the IP address of your providers GGSN, and for a standard consumer connection this is going to be where the buck stops.
Now that said, IF you have the budget, and all your devices (Assuming multiple ones) are with the same carrier, then you can approach the carrier and request a dedicated APN (Access point name) essentially what this is , is the mobile network equivalent of a DNS record, or at least similar enough to use that analogy anyway.
When you set up your data connection on your device you may recall having to enter something like 'pp.vodafone.com' or 'INGhub411.o2-uk.inbound' we'll this is your actual APN, and if you have a custom one they your devices can be set up so that the IP the presents itself at the GGSN actually has a static route back to the individual device in the suppliers GSM network.
As a general rule of thumb however on consumer grade connections this is not enabled and hence there is no ingress available to the individual device.
As zmbq says, the ONLY option you have is for the device to keep polling the server on a regular basis, and yes unfortunately that is going to be very unforgiving on the battery.
of course there is one other way of approaching this, and that's to have the device open a socket directly to your server then keep that socket open. Once the socket is open, 2 way communication can be performed across the link, unfortunately your going to also have to write all the code to manage this connection including, but not limited to monitoring the connection to make sure it's still open and re-establishing it if it's not, something which is incredibly important on a mobile device.
I have a Visual C++ programm with a proprietary point-to-point protocol built on top of TCP/IP sockets that allows a set of messages to be flow between a third party software.
There is a note in documentation to that protocol:
IP logical packets do not necessarily map directly to physical packets on the underlying network socket, they may be broken apart or aggregated by the TCP/IP stack.
What does this mean?
I've write my C# application to connect and due to technical restriction it is able to run and communicate only locally. Plus every millisecond is critical.
Seems this is not about named pipes: pipelist.exe doesn't show any specific entries.
If you are just using loopback there may be no IP packets at all, and in any case (a) the implementor of your protocol should have already taken all that into account and (b) TCP hides all that from you too - it just provides a byte stream interface.
When TCP/IP packets go out over, say, Ethernet, the packets are repackaged as Ethernet frames. This may include breaking up the original packets.
When the frames arrive at their destination, the Ethernet header information is removed and the original packet (reassembled if necessary) is presented to the TCP/IP layer on the destination machine.
But this repackaging can also happen within the TCP/IP stack. TCP and IP are actually separate protocols; IP is responsible for routing, TCP does the "handshaking" (maintains session state, guarantees delivery [or tries to], etc.)
Named pipes are a completely different interprocess communication mechanism. Usually faster than TCP/IP, but typically restricted to use on a single machine, I believe.
IP logical packets do not necessarily map directly to physical packets on the underlying network socket, they may be broken apart or aggregated by the TCP/IP stack.
TCP/IP is not the lowest level network protocol that exists. There are others: the Ethernet protocol that connects ethernet devices, the 802.11x wireless protocols, and others. All this statement says is that a single IP packet may correspond to multiple packets in the lower-level protocols, and that the IP networking layer is responsible for buffering or joining these packets.
Your application shouldn't need to worry about this at all. TCP/IP networking is handled very efficiently by all modern OS kernels, and unless your requirements are very unusual you should never have to worry about the way your application protocol is broken up into packets by TCP/IP or the lower-level protocols.