I want to write a program from scratch to see the sockets activity, what they send, what they receive, etc. I don't want to use a Library because it's more for academic purposes than anything else.
Where should I start?
Just to be clear: my program won't be connecting to anything or creating any socket, it just wants to listen to the activity in a computer.
Any thoughts (in any OS) about where to start will be appreciated.
Thanks in advance.
Take a look at libpcap/WinPcap.
You are out of luck as far as portability goes.
Although the application APIs are the same or similar for UNIX and Windows, and, both implementations are historically based on the same Berkeley Sockets BSD code, the operating system architecture and hence the ways you access low level OS functions such as network IO are completely different.
Linux has a number of 'network sniffing' tools(tcpdump, ethereal etc.) easily available. Not so sure about windows, MS provides a Network Monitor and there are some tools available -- Google 'Sysinternals TDImon' for the MS tools.
Related
I am communicating across USB, using a proprietary protocol, with some custom hardware I've built. I have a GUI that handles all the communications/interaction with that hardware and a (C#) DLL which exposes all the relevant USB functionality. I need to write a LabVIEW driver (VI) for communicating with the hardware. My thought is that I just use LabVIEW to open up my GUI and have a socket with which I expose all the relevant control to LabVIEW with. Is it possible to open a socket in LabVIEW and communicate with my GUI? Is this a bad approach or should I just try and make LabVIEW invoke the DLL and handle the hardware control instead of my GUI (polled communications, solicited/unsolicited commands, etc)?
IS there a reason you want to use your GUI only? In terms of time, I would say build a good front panel in LabVIEW and just communicate to the hardware directly using the DLL. Adding the GUI is just an added layer of complexity which might be difficult to maintain later on? Why not do everything in LabVIEW if you can?
Yes, LabVIEW supports sockets using both TCP/IP and UDP.
You should be able to create a program/service that continually runs acting as TCP/IP server. You can send commands and receive responses as strings. If you need to pack data, you can use the flatten to string command.
Essentially, your application should be structured as a loop running the TCP/IP server, and another loop that actually communicates with the instrument. This might change if you need to get data back from the devices to your TCP client. A producer consumer model, if you will :)
To get you started off, open up the NI Example Finder (Help -> Find Examples) and browse to Networking->TCP and UDP-> Simple Data Server.vi
It depends who is going to be using the LabVIEW driver and for what. If you're handing over this hardware to someone else who is going to want to create their own application(s) for it, they would probably prefer to talk directly to the DLL rather than go through your GUI. If it's more about automating your existing software from LabVIEW to do testing or repetitive tasks on the hardware, for example, then driving your GUI from LabVIEW might be less work.
I'm writing some Perl code. I want it to run on Windows and Linux/UNIX/OSX. So far it works on *NIX and uses fifos.
I am considering switching to sockets to avoid the problem that POSIX::mkfifo() doesn't work on Windows, so I need to write some separate code to use Win32::Pipe.
I'm feeling ambivalent about the whole thing. It seems to me both fixes require about the same amount of work. Is it a good idea to switch to sockets?
Short answer: IO::Socket::INET works on both Windows and *NIX.
Named Pipes
Slightly easier to code up quickly. You don't need write connect code.
Slightly faster. Sockets have the overhead of TCP and setting up the initial connection.
Works on all platforms.
Works even when network card doesn't exist. Some laptops shut down the network card to save power which can prevent even local sockets from working.
Sockets
Works on all platforms. However, some laptops shut down the network card to save power and even local sockets won't work if there is no network interface.
More portable in Perl. IO::Socket::INET works on both *NIX and Windows.
Allows you to have a separate conversation with each client.
Firewalls are not a problem. Ports over 1024 should work.
Personally, I've decided to switch to sockets. In my application it doesn't matter much. But I think it makes the code a bit simpler, gives me the flexibility to move to > 1 client in the future, and I want to learn IO::Socket anyway.
Answering more generically (ie, it's not perl specific):
Doing this sort of thing in windows vs the rest of the world almost always requires separate code for windows vs everything-else. Pretty much everything-else has good solutions for things like this, like unix file sockets or fifo's or ... Then on windows you have to fall back to sockets.
The right thing to do, IMHO, is to use the right solution on windows that isn't network sockets because that opens the application up to security issues. So on everything else "do it correctly" but then on windows, fall back to something like network sockets instead. But, make sure if you take the network-socket route you should at least use local sockets only (ie, bound to 127.0.0.1).
For perl, I'd be tempted to look in CPAN for a class that's already made this generic. But... I wouldn't be surprised if nothing exists.
LWP::socket works fine in Windows and *NIX. If you opt for sockets over fifos, then you eventually would be able to communicate Windows and *NIX processes. May be you don't need it today, but who knows.
IIRC, later versions of Perl have a working socketpair on Windows.
I want to make a Wi-Fi controlled robot.
After a lot of research, I decided to use an Asynclab's BlackWidow which was the best way for me to do this.
But unfortunately, this product is out of stock everywhere!
I ordered one on roboshop and I got the message 25 days later: Sorry, this product is sold out.
So, I'm looking for another microcontroller with a Wi-Fi interface.
I also need this very quickly (because it is for a school project), and it must be as cheap as possible.
I've been looking all the day but I couldn't find something as "good" as the BlackWidow.
You can get the WiFly shield from sparkfun.
In the past I have used a Linux router (with positive results) with Gargoyle (OpenWrt based) as a wireless gateway and communicate with it through a serial port, as most of them attach a console to the serial port so that you just have to send the command and '\n' to be executed. With the cURL libraries should be fairly easy to communicate without much effort with whatever you want.
You have the power of Linux and a pretty powerful CPU, can configure it through the command line or web page, and most important, a lot of routers are much cheaper than the 'BlackWidow'.
The one I used is the Fonera+ (unmounted doesn't take much more space than an Ethernet Shield) and used to cost around $28 although it is now deprecated, but some other routers from Linksys, TP-Link, etc. are also compatible as stated in the OpenWrt Compatibility Table.
I have a Java-program which communicates with a C++ program using a socket on localhost. Can I expect to gain any performance (either latency, bandwidth, or both) by moving to use a native OS pipe? I'm primarily interested in Windows at the moment, but any insight related to Unix/Linux/OSX is welcome as well.
EDIT: Clarification: both programs run on the same host, currently communicating via a socket, i.e. by making a TCP/IP connection to localhost:. My question was what are the potential performance benefits of switching to using (local) named pipes (Windows), or their Unix equivalent (AF_UNIX domain socket?).
Ken is right. Named pipes are definitely faster on Windows. On UNIX & Linux, you'd want a UDS or local pipe. Same thing, different name.
Anything other than sockets will be faster for local communication. This includes memory mapped files, local pipes, shared memory, COM, etc.
The first google hit turned up this, which clocked NT4 and XP and found named pipes (that's what you meant, right?) to be faster on Windows.
For local processes communication pipes are definitely faster than sockets. There is a benchmark.
I think even though socket is flexible but it can also lead to bad code design. While using pipe it enforces you to design the architecture of your project like which process should be the parent which should be the children and how they cooperate(this will determine how pipes are established) and assign different functionality to processes. Your project design this way will have hierarchical structure and easy to maintain.
Is there any benefit on Windows to use the WSA winsock functions compared to the BSD-style ones?
The most significant difference is the availability of Asynchronous Event style APIs in Winsock.
With Berkeley sockets, each time you read or write your application will "block" until the network is ready, which could make your application unresponsive (unless the network I/O is handled in a different thread).
With an async interface, you can arrange for a callback function to be called as part of the normal windows message loop each time data is received or when the transmit buffer is empty.
Only if you plan to deploy to a legacy platform like Windows 95 or there is something in the winsock API that you absolutely cannot live without and you don't want to roll yourself (<-- doubtful tho).
If you design around the BSD paradigm, your code can work on other platforms with less porting work. If you assume that your network library will support asynchronous I/O (as Alnitak mentions), you're going to have to do a lot more work if that gets pulled out from under you.
Of course, if you're sure you'll never leave the warm bosom of Microsoft, feel free to go to town.
With respect to Alnitak's answer, I agree - I'd just add that you need not use a message loop to use asynch operations on sockets. Using I/O completion ports is a very scalable way to build a high-performance networked application.