I am doing some maintenance on software and have a problem that I do not understand.
Application was developed using Microsoft Visual C++ 6 and runs on Windows XP. It consists of 21 applications that communicate to each other via UDP sockets. It is a simulation of an embedded avionics system used to debug the system in a PC environment. Each of the applications simulates a node in the embedded system and the embedded networked is simulated over UDP. The system originally ran on multiple PCs but can now runs on a single Quad core machine.
The system is working but the communication is annoyingly slow. However opening up Internet Explorer and visiting a web site or two set something that would cause my applications to suddenly communicate very fast to each other.
So my question is what did Internet Explorer set when visiting a web site so that my application can also set it? None of the original authors of the system is still around and I have very little windows programming experience.
it might not be a windows problem after all
check your API, check your buffer and check for errormessages 'getlasterror()' that doesn't cause INVALID (-1) and stops the program try to use it even if your program runs perfectit might have useful warnings
check ACK or attack speed it's a common issue at transfer large amounts of data over network connections ( <-- 90% it's your problem ), here is a useful topic on that subject ( support.microsoft.com/kb/823764 )
if neither of those solutions work, try checking your driver version against the manfucturer website.
last resort is those useful ideas:
. use this program www.lvllord.de to increase max half/open connections from 8 to 50
. using a server edition windows can boost some internet based programs
. using multi-threading with sockets API can cause some confusing to the API if you're using more than 2 sockets at different threads in multithreaded application, try optimize performance by using async sockets or something like that ( msdn.microsoft.com/en-us/library/ms738551(VS.85).aspx )
So my question is what did Internet Explorer set when visiting a web site so that my application can also set it? None of the original authors of the system is still around and I have very little windows programming experience.
may be ACK check it on wiki .. it means in other ways the attack speed .. if not then it will be the receive window size
both settings are invisible to users .. but can be set via programs such as tuneup utilities or any general network hidden setting adjustors
it might just do the trick ..
If the protocol above UDP implements reliability the speed loss will be due to massive UDP packet loss on localhost. UDP performance on localhost is terrible, your best bet is to wrap the socket API inside a TCP layer.
If it's UDP broadcast or multicast you will have to look at implementing a broker process to multiplex the messages over TCP.
Might be easier to look at existing messaging APIs that work well at the interprocess level such as ZeroMQ.
Try using Wireshark to see what Internet Explorer is doing.
Related
I was trying to find traceroute program implementation for MS Windows that can be used by regular user (with no admin rights) and I could not find any. Those I could find (like tracetcp or nmap) require PCAP library and in order to install winpcap I think administration rights are required.
I don't know much about Windows internals but I'm wondering what is the 'magic' behind. If tracert shipped by MS with Win OS works fine for regular user (but it can use ICMP only) then is there any issue (technical limitation) with setting TTL for TCP/UDP packet by regular user and receiving respective response on the socket such as:
ICMP: TTL expired in transit
UDP: port unreachable
and probably few others (like TCP RST, ICMP host unreachable etc)?
So basically:
if there is no issue why there is no reasonable traceroute implementation
for windows?
if there is a technical limitation for TCP/UDP then why
original MS ICMP traceroute works fine for non admin users?
I know that the most popular linux traceroute with -T option (for using SYN probes) requires root priviliges too but I'm assuming it's just because it does not want to complete full TCP handshake and sending RST after receiving SYN-ACK may be restricted for root. Anyway as longs as TTL can be set by reqular user (for UDP it seems to work fine) then I would imagine TCP traceroute completing full TCP handshake should be possible to implement for non root linux users?
And by the way ICMP traceroute also needs admin rights because of using RAW sockets but surprisingly for Windows it does not seem to be an issue.
Sadly, the simple answer to your question is "no, there is no native way to do that on a Windows box".
I am a bit unsure about your specific usecase, but one route to go is evaluate if Power Shell has more functionality to help you out. Jose Baretto from Microsoft wrote an article about Power Shell equivalents for common networking commands. You can find it here:
https://blogs.technet.microsoft.com/josebda/2015/04/18/windows-powershell-equivalents-for-common-networking-commands-ipconfig-ping-nslookup/
Failing that, your only option is (as you mention yourself) 3rd party tools, and you'll be hard press to find one that doesn't require elevated privileges.
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 discovered almost accidentally that my machine was sending and receiving UDP packets to a machine in Poland. Not that I have any problem with Poland, I just don't know why my laptop has the need to communicate with a server there. Reverse DNS shows just the ISP providing the address to some end user. Using Wireshark, I can monitor the messages, which were indecipherable as they were probably encrypted. All packets sent from my machine had the same source port, so clearly the application that sent them opened this UDP socket to use it. I am searching for ways to:
1) enumerate all current sockets open in the system, including the process that created it and, for both TCP and UDP, what ports and addresses they are current bound to.
2) because applications can open these sockets, use them, and close them right away, I would love to find (or perhaps even write) a program that once started would somehow get notification each time a socket gets created, or really more importantly when bound to a source and/or destination address and port. For UDP, I would love to also be able to monitor/keep track of the destination IP addresses and ports that socket has sent messages to.
I don't want to monitor the traffic itself, I have Wireshark if I want to view the traffic. I want to be able to then cross reference to discover what application is generating the packets. I want to know if it is from a process I trust, or if it is something I need to investigate further.
Does anybody know of any applications (for the Windows platform) that can do this? If not, any ideas about a .NET or Windows API that provides this capability, should I want to write it myself?
Edit:
After further research - looks like the APIs to use are GetExtendedUdpTable and GetExtendedTcpTable, CodeProject.com has some samples wrapping these in .NET (see http://www.codeproject.com/Articles/14423/Getting-the-active-TCP-UDP-connections-using-the-G). So a combination of this API and some sniffer code would be needed to monitor and keep track of what hosts at what ports using what protocol any particular application on your machine is talking to. If I ever get some free time, I'll consider creating this, if you know of an app that does all this, please let me know.
Try SysInternals TCPView. Despite its name, it handles UDP as well.
netstat -b to enumerate all ports along with the process names.
You can try using SysInternals' Process MOnitor (ProcMon.exe or ProcMon64.exe).
It allows for filtering of Processes by "UDP Send" Operation - and provides detailed UDP Connection data, including source and destination addresses(IP) and ports etc.
Are there any reasons for favoring named pipes over sockets for local IPC (both using win-api), effectiveness-wize, resource-wize or otherwise, since both behave very much alike (and likely to be abstracted by a similiar interface anyway), in an application that is likely to already use sockets for network purposes anyway?
I can name at least the addressing issue: port numbers for sockets against filenames for pipes. Also, named pipes (AFAIK) won't alert the firewall (block/unblock dialog), although blocked applications can still communicate via sockets locally. Anything else to take into account?
In the case of using sockets, are there any winsock settings/flags that are recomended when using sockets locally?
Some subtle differences:
Sockets won't work for local IPC if you don't have a functioning adapter. How common is it to have a PC without a functioning adapter? Well, I got bitten when somebody tried to demonstrate our software to a customer on a laptop that was not plugged in to a network or a power supply (so the OS disabled the network card to save power) and the wireless adapter was disabled (because the laptop user didn't use wireless). You can get around this by installing a loopback adapter but that's not ideal.
Firewall software can cause problems with establishing TCP/IP connections. It's not supposed to be an issue for local IPC, but I'm not convinced. Named pipes can have firewalls too.
You may have issues due to the privileges needed to create named pipes, or to create new instances of named pipes. For instance, I was running multiple servers using the same named pipe (probably not a good idea, but this was for testing) and some failed in CreateNamedPipe because the first server to create the pipe was running in Administrator mode (because it was launched from Visual Studio in Administrator mode) while the rest were launched from the command line with normal UAC level.
Although the article mentioned by Rubens is mostly about IPC over a network, it does make the point that "Local named pipes runs in kernel mode and is extremely fast".
Another solution you may want to consider is a named shared memory region. It is a little bit of work because you have to establish a flow control protocol yourself, but I have used this successfully in the past where speed was the most important thing.
The project I'm working on is to handle data capture from scan guns (Pocket PC 2003) and process this data on a host (Win XP) then into our inventory database on a separate server (Win 2000). This is all driven by the Remoting framework provided by MS and As Good As It Gets (http://gotcf.net). The application is complete enough for a general proof of concept with both the client and server working properly while in the emulator.
All is well until I began to test using actual scan guns. Due to security concerns, the scanners are on a separate network (for clarification the 10 network) than the server (the 15 network). My development machine has dual NIC connected to both networks and can communicate with both independently. However, I am having issues with my application receiving information from the 10 network using .Net Remoting, and then sending out information to the server on the 15 network via a third party app (Combination of ODBC, Btrieve, and OLE).
Is there anyway to process information from one network then update the server on another?
Any suggestions will be greatly appreciated!
Note: I'm not very familiar with networking, thus I may be calling it the wrong name but the gun IP's start with 10...* and the server IP's start with 15...*
So long as the computer's routing table is properly configured, you shouldn't have to worry about this from your application. So long as you're using the proper IP addresses, the networking stack should take care of delivering things to the right place.
You might want to check the output of "route print" (at least I think that was available on WinXp -- if not, someone else will likely post the correct command for XP soon). In any way, you should see what network destinations are configured for which interfaces. You'll need to make sure that the server's IP on the 15 network will properly route via the interface you want (ie. the lowest-cost matching destination/netmask lists your 15 interface).
The issue seems to stem from both the NIC cards not set up properly and a so far unresolved issue with the frameworks I've chosen.
To solve the NIC problem, the easiest solution I'd found had me clear the default gateway on the 10 network.
The other issue deals with recreating the remoting objects after they've been destroyed. I currently have to warm boot the scanner in order to re-connect to the host. In order to correct this issue I'm going to contact As Good As It Gets to see what their input is. Damn firewall