I wish to know that If protocol family AF_INET is used for local communication (IPC) in windows systems. (with loopback interface) will it be able to give performance same as AF_UNIX in unix. I tried for Named pipe in windows but it doesn't seems to me working for my case.
AF_INET when used it will go through the TCP/IP stack. which will be overhead in case of intranode communication.
Please let me know for any clarification.
The IPC using the loopback interface is quiet fast. I can't compare the performance with a AF_UNIX implementation. But it should give you a similar programming interface (sockets).
For high performance IPC you might consider using shared memory. But in that case you would miss the comfort of the streaming communication as you find with sockets.
You should also check, what requirement leads you to the performance question?
Related
First allow me to say that I don't have any experience developing drivers for OSX, nor drivers for Windows. So, there are a lot of things that I don't understand about how drivers work; I'm sure it'll be evident in my question.
I have a modem that is able to open and close TCP/UDP sockets using AT commands. I would like to create some kind of program (kernel extension? driver?) that implements a network driver, converting the network interface calls into AT command serial messages.
That's the basic jist of it. I'm essentially asking if anybody can point me in the right direction / give me a high level overview of how they would approach it and what Apple guides to focus on.
The XNU networking stack -- like most network stacks -- expects network devices to send and receive IP packets directly. It isn't tooled to work with network devices that handle part of the network stack (like TCP or UDP) internally -- it won't be possible to implement a network driver which uses this device.
You might have more luck exposing this device as a SOCKS proxy. You will need to write a userspace daemon which listens on a TCP port on localhost (on the computer) and relays traffic to the serial device; once that's done, you can set the computer to use that device as a SOCKS proxy in the Networking control panel.
(As an aside: most devices that implement this type of interface have a very low limit on the number of open sockets -- often fewer than 10. They're unlikely to be able to handle the network load generated by a desktop OS.)
I'm a beginner to ethernet programming, I want to access the ethernet port and send/recieve packets to/from it. I thought of using the CIM_EthernetPort class, but don't know how to do it. please help. I have to write a program to send data to an embedded system.
I don't think you quite understand what sockets are.
What protocol does your embedded device use? If it's TCP or UDP (or even a raw link protocol) it's pretty much using a socket by definition.
The only reason you might need to talk to an ethernet adapter without using sockets is if you want to write something like a wire level monitor or packet sniffer.
ps -------------------------------------------------------------
Sockets are just an abstraction of a network connection, since a UDP connection has an endpoint and a port it's a bit philosophical wether you are using sockets if you talk directly to the network card hardware.
You don't specify a baud rate as such on ethernet, the card hw will negotiate a speed.
There is very little overhead in sending data by UDP using sockets and it's usually a very efficent way of receiving data. Do you have an RTOS on the embedded device or were you trying to talk to the network adaptor directly with some sort of polling?
pps ------------------------------------------------------------------
If it is at all possible to use UDP on the embedded device - DO SO.
If you start with, I just need to send a few numbers, you ultimately end up re-inventing and re-solving all the things UDP was invented to do.
By using standard protocols you also get tools to let you test each end of the connection (there are UDP equivalents of hyperterm for free).
Also there is no need for multiple devices now, but there may be in the future. I argued for using UDP on a previous product I worked on - where the designers were thinking of ethernet as just a faster serial link. Being able to network many units of this product together has created a huge new market.
Preliminary story
There is this program which uses the Parallel Port to synchronize with other hardware. It will set the Parallel Port output to a specified (byte) value. This works without problems when using the built-in Parallel Port of a PC. The target platforms are Windows XP to 7, all worked fine so far. Source code is in Delphi, accessible and can be modified.
How it works
In Delphi I can use the io.dll to set the value of the Parallel Port, but there are also other solutions available, like inpout32.dll or port.dll. I call something like PortOut, specify a port number and the byte value and the port is set.
What I now want to do - and where I need help
Now the change: this needs to work on a machine which has no Parallel Port built-in (not even on the mainboard). There are several options available:
use a USB to Parallel Port adapter to add a LPT port to the PC
use a PCI card which adds a LPT port to the PC
use a PCI Express card which adds a LPT port to the PC
I am currently heading for and concentrating on the easiest and cheapest possibility: a USB to Parallel Port adapter.
Main question
There seem to be differences between Parallel Port adapters which are made to connect just a printer and other adapters which seem to be more powerful. Is there really a difference? Or can I just use one of these 5$ printer-adapters, plug in my own hardware and access the port from Delphi code? Or do I need a special adapter? Has anyone experience with this? There is a related question here, but the different adapter types (if existent) are not mentioned there. This page suggests that there are indeed differences:
Contrary to all other USB parallel ports which can connect to printers only, this makes connection to most hardware.
I hope there exists a solution via USB because for this you don't have to open the PC, which means the adapter can be added on demand.
Sub-question
Do you have experience with PCI (Express) solution? I have to use one if the USB approach is not successful.
Since I've been wrestling with this very thing recently here's what I've discovered; If you mean by using IO port addressing (indicated by your reference to inpout32.dll), no. Unless your USB-parallel port driver supports full port emulation or virtualization, which most do not, this is generally not possible. If you need to directly access the port to do normal "bit-twiddling", you should get a separate Parallel port PCI-card. Most of them present themselves as normal IO at the standard address(es). I am presuming you're not planning on using the parallel port to actually communicate with a printer, right?
What is interesting is that USB-Serial adapters are much easier to use since they appear as simple virtual devices where you can merely "open" them using a simple stream; TFileStream.Create("COM1", fmOpenRead) or Windows.CreateFile("COM2", ...);
Here is some devices that purport to do full emulation of a parallel port through USB:
https://www-user.tu-chemnitz.de/~ygu/bastelecke/PC/USB2LPT/index.en.htm
Does anyone know a good method for mapping devices on a network?
I am looking for something that can establish the connection layout between devices to build a visual network diagram.
Any ideas?
This isn't an algorithm, but rather a protocol (or protocols) for discovering neighbors. If your switches/devices have Link Layer Discovery Protocol (LLDP) enabled, you can use that to determine a network of physical connections.
Note that older Cisco switches might not have LLDP, but will have CDP, a proprietary implementation of discovery. Same goes for Nortel and Extreme switches which also have their proprietary protocols. But LLDP is now the standard (802.1AB) that should be used for discovery.
You can also see on the Wikipedia page that there are implementations of LLDP (and other proprietary protocols) for Linux/Windows/Mac. Also, VMware ESX implements CDP.
I wonder if the UNIX domain socket connections with postgresql are faster then tcp connections from localhost in high concurrency rate and if it does, by how much?
Postgres core developer Bruce Momjian has blogged about this topic. Momjian states, "Unix-domain socket communication is measurably faster." He measured query network performance showing that the local domain socket was 33% faster than using the TCP/IP stack.
UNIX domain sockets should offer better performance than TCP sockets over loopback interface (less copying of data, fewer context switches), but I don't know whether the performance increase can be demonstrated with PostgreSQL.
I found a small comparison on the FreeBSD mailinglist: http://lists.freebsd.org/pipermail/freebsd-performance/2005-February/001143.html.
I believe that UNIX domain sockets in theory give better throughput than TCP sockets on the loopback interface, but in practice the difference is probably negligible.
Data carried over UNIX domain sockets don't have to go up and down through the IP stack layers.
re: Alexander's answer. AFAIK you shouldn't get any more than one context switch or data copy in each direction (i.e. for each read() or write()), hence why I believe the difference will be negligble. The IP stack doesn't need to copy the packet as it moves between layers, but it does have to manipulate internal data structures to add and remove higher-layer packet headers.
afaik, unix domain socket (UDS) work like system pipes and it send ONLY data, not send checksum and other additional info, not use three-way handshake as TCP sockets...
ps: maybe UDS will be more faster
TCP sockets on localhost are usually implemented using UNIX domain sockets, so the answer on most systems is neglijable to none. However, this is not standard in any way -- it is just how usually it is done, therefore you should not depend on this.