I have a Windows application that utilizes a 3rd-party tool (FaxMan) to send faxes via a COM port attached to the PC. In order to stress test my application I want to create some virtual COM ports that pretend to have fax modems attached. I then want to 'spoof' the sending of faxes, without physically sending anything. The virtual COM ports would need to respond to standard AT commands as if the fax was being sent. The ability to spoof failures would be an added bonus.
My first thoughts are using a virtual COM port driver to redirect to a telnet or other TCP session - I could then have a TCP server that pretends to go through the fax motions. However, I am happy to pay for a component if one exists.
I worked on this problem for several years, developing a LAN fax product. I doubt you can do it well.
Developing a virtual COM driver means developing a kernel driver (unless you can buy one off the shelf): which is doable (I did it) but I'd guess it's far more trouble than it's worth (I'd be surprised if it's worth your while).
Another problem is that there are a variety of fax modems and fax modem standards (and you say you're hoping to emulate one well enough to fool FaxMan).
Another (essential) problem is that the simpler (non-error-correcting) fax protocols are a (hard) real-time protocol: there is some (more or less) buffering on the fax modem, but the PC attached to the fax modem cannot to afford to underrun when sending or to overrun when receiving ... which means that redirecting this traffic via telnet (with the TCP timers and buffers) either breaks the fax session at worst (FaxMan will time out) or at best mean that your testing isn't representative of what the real-world (non-emulated) performance will be.
What are you trying to stress-test anyway: your application, or the third-party FaxMan?
I suggest that the cheapest solution and the most realistic test would be using real hardware: real COM ports, real fax modems, and real (or, possibly, simulated) telephone lines.
Edit to answer the questions from the comments in Michael's answer
Assuming that the transport of the data is a small problem (e.g. because you can simply connect two serial ports back to back), is writing software which emulates a fax modem a small problem?
It might be small: if your load test is merely "send fax data to the bit bucket" then your emulated modem mostly just needs to respond "OK" to every/anything that looks like an AT command, plus various other responses to the various fax-specific AT+F_whatever_ commands. But that's a pretty low-fidelity, not a very stringent, test.
That would be pretty simple - but isn't there some protocol involved in the FAX data transmission? Or is the protocol just a variant of the AT command set, and spoofing an "OK" is all there is to it? I honestly don't know, but I assumed there would be a somewhat more complex protocol.
The telephony protocols have names like "T.4" and "T.30". The PC-to-faxmodem protocol is usually a protocol called "class 1 fax" or "class 2 fax". The latter ("class 2" or "class 2.0") is the higher-level of the two: more ASCII and less binary data, not so timing-sensitive (class 1 is sensitive to 10s of msec iirc), because it encapsulates/wraps more of the underlying T.30 negotiation than class 1 does; it consists of extended AT commands (i.e. AT+F_something_ commands, and their responses) plus a dump of the binary-encoded fax image data.
Some of the responses are more than just "OK" (i.e. they represent the available/negotiated fax session parameters) but (in class 2 rather than class 1) they're ASCII-encoded rather than binary, so not too difficult really at all.
There has to be some sort of handshaking, right? Otherwise a plain, old FAX machine would likely lose a bunch of data when it was loading a new page.
Yes there's some handshaking ("May I send now?") between pages (i.e. before each page). A load-testing emulation which isn't testing the timing would just respond "yeah, go ahead (I'm only going to be dumping the data into the bit bucket anyway without even looking at it, so what do I care)" to the handshake enquiry.
The emulation would also have to watch the binary image data (which it's getting from the PC) for <DLE><ETX> and <DLE><DLE>, in order to respond OK at the end of the PC-dumps-image-data-to-the-modem.
I don't know what timers might be built into the FaxMan application (whether or not you might need to add artifical delays to your emulated responses, to prevent FaxMan's realising that the responses are abnormally quick): maybe not, but maybe.
There may or may not be any hand-shaking within the page:
With older fax machines/fax protocols, there isn't: instead the devices negotiate 'fax session parameters', including the baud rate, before the page: they negotiate a synchronous baud rate which both ends are able to support. That (ability to handle a whole page-worth of data, synchronously) is part of why it's a hard-real-time protocol.
Newer fax machines / fax protocols support 'error correction' within each page: the page is sent in smaller (but still synchrnonous) chunks: and each chunk acknowledged, or NAKed and retransmitted.
I think that ChrisW's advice is sound - particularly getting telephone line simulators - they're not too expensive and were very useful back when I did modem driver work.
That said, there is an open source driver package that (according to their claims) lets you set up pairs of virtual com ports: http://com0com.sourceforge.net/
You could connect the FaxMan application to one COM port then a FAX 'simulator' that handled the AT command set and whatever is in the FAX protocol you want to test. This sounds like what you were looking for - but...
I have no idea how well the com0com drivers work - I've never even downloaded them much less tried them (I'm not sure I should even post this answer...)
I have no idea how much work would be involved in writing a FAX simulation; I imagine it's no small task.
Virtual modem: http://www.eltima.com/products/virtual-modem-pro/
Related
I'm building an application that uses TCP sockets to communicate. I want to test how it behaves under slow-speed conditions.
There are similar question on the site, but as I understand it, they deal with HTTP traffic, or are about Linux. My traffic is not HTTP, just ordinary TCP sockets, and the OS is Windows.
I tried using fiddler's setting for Modem Speed but it didn't work, it seems to work only for HTTP connections.
While it is true that you probably want to invest in an extensive set of unit tests, You can simulate various network conditions using VMWare Workstation:
You will have to install a virtual machine for testing, setup bridged networking (for the vm to access your real network) and upload your code to the vm.
After that you can start changing the settings and see how your application performs.
NetLimiter can also be used, but it has fewer options (in your case, packet loss is very interesting to test and is not available in netlimiter).
There is an excellent utility for Windows that can do throttling and much more:
https://jagt.github.io/clumsy/
I think you're taking the wrong approach here.
You can achieve everything that you need with some well designed unit tests. All of the things that a slow network link causes can be simulated in a unit test environment in controlled conditions.
Things that your code MUST handle to deal with "slow" links are just things that you should be dealing with anyway, including:
The correct handling of fragmented messages. All of your network reading code needs to correctly assume that each read will return between 1 byte and the size of your read buffer. You should never assume that you'll get complete 'messages' as TCP knows nothing of your concept of messages.
TCP flow control causing either your synchronous sends to fail with some form of 'try later' error or your async sends to succeed and potentially use an uncontrolled amount of resources (see here for more details). Note that this can happen even on 'fast' links if you are sending faster than the receiver is consuming.
Timeouts - again this isn't limited to "slow" links. All of your timeout handling code should be robust and tested. You may want to make sure that any read timeout is based on any read completing rather than reading a complete message in x time. You may be getting your data at a slow rate but whilst you're still getting data the link is alive.
Connection failure - again not something specific to "slow" links. You need to know how you deal with connections being reset at any time.
In summary nothing you can achieve by running your client and server on a simulated slow network cannot be achieved with a decent set of unit tests and everything that you would want to test on such a link is something that could affect any of your connections on any speed of link.
I'm planing to start some sms based application and currently in feasibility study part. In my application client have to sms their problem to the server and we have to analyse the problem and take reasonable action. Also We have to find the tentative location through which tower they have been connected. I have seen about silent sms feature but not understand. Is any body have experience on how to detect location of sms creator (not in android or iphone). Please help me on determining whether it is possible or not to find the location. If possible then how?
In short this is not possible.
an SMS message weather in PDU mode or text mode does not carry the information to match the source location to the message in any way shape or form.
With reference to the article you linked to in your opening post, I'm sorry to say that there's so much B$$l S$$t in that post that I can smell it from here.
In all the years Iv'e worked with GSM systems, both as a network maintenance engineer and later as a developer writing software to use these systems, not once have I heard of anything such as an 'LMU' or an 'E-OTD' in fact the only acronym that article really got correct was 'BTS' oh and the bit on passing the data over the signalling channel.
As for the silent SMS, well that part actually is true. The special type of SMS they refer to is actually called a Ping-SMS and it exists for exactly the same reason that a regular PING on a TCP/IP network exists, and that's to see if the remote system is alive and responding.
What it's NOT used for is the purpose outlined in the article, and that's for criminal gangs to send it to your phone and find out where you are.
For one, the ONLY people that can correctly send these messages are the telephone operator themselves. That's not to say that it's impossible to send one from a consumer device by directly programming a PDU if you have the necessary equipment and know how. You could for instance pull this stunt off using a normal GSM modem, a batch of AT commands and some serious bit twiddling.
However, since this message would by it's very nature have to go through your operators SMSC and most operators filter out anything from a subscriber connection that's not deemed regular consumer traffic, then there's a high chance this would fail.
You could if you had an account, also send this message using a web sms provider that allowed you to directly construct binary messages, but again they are likely to filter out anything not deemed consumer grade messages.
Finally, if you where to manage to send an SMS to a target device, the target device would not reply with anything anywhere near a chunk of location based info, cell tower, GPS or otherwise. The reason the SMS operators (and ultimately the law enforcement agencies know this info) is because EVERY handset that's attached to the GSM network MUST register itself in the operators MSC (Mobile switching centre), this registration (Known as ratching up) is required by the network so it can track what channels are in use by which device on which towers so that it knows where to send paging and signalling info.
Because of the way the PING SMS works it causes the destination device to re-register itself, usually forcing the MSC to do a location update on the handset which causes a re-registration.
Even then, all you get in the MSC is an identifier of the cell site the device is attached too, so unless you have a database in the organisation of all cell sites along with their exact lat/long co-ordinates, it's really not going to help you all that much.
As for the triangulation aspect, well for that to work you'd need to know at least 2 other transmitters that the device in question can see, and what's more you'd need that device to report that info back to someone inside the network.
Since typically it's only the Ril (Radio interface layer) on the device that actually keeps track of which transmitters it can see, and since the AT commands for many consumer grade GSM modems have the ability to query this information disabled, then it's often not easy to get that info without actually hacking the firmware in the device in question.
How does Google do it? well quite easy, they actually have commercial agreements with network providers that pass the details of registered towers to their back-end infrastructure, in the apps themselves, they have ways of getting the 'BSS List' and sending that list back to Google HQ, where it's cross referenced with the data from the network operator, and the info they have in their own very large transmitter database and finally all this is mashed together with some insane maths to get an approximate location.
Some GSM Modems and some Mobile phone handsets do have the required AT commands enabled to allow you to get this information easy, and if you can then match that information to your own database you can locate the handset your running from, but being able to send a special SMS to another device and get location info back is just a pipe dream nothing more, something like this is only going to work if your target device is already running some custom software that you can control, and if your device is running software that someone else is controlling, then you have bigger problems to worry about.
Background
I want to create a test application to test the network performance of different systems. To do this I plan to have that machine send out Ethernet frames over a private (otherwise non-busy) network to another machine (or device) that simply receives the message and sends it back. The sending application will record total roundtrip time (among other things).
The purpose of the tests is to see how a particular system (OS + components etc.) performs when it comes to networking traffic. This is illustrated as machine A in the picture below. Note that I'm not interested in the performance of the networking infrastructure (switches, cables etc) - I'm trying to test the performance of network traffic inside Machine A (i.e from when it hits the network card until it reaches user space)
We will (try to) measure all kind of things, one thing is the total roundtrip of the message but also things like interrupt latency of Machine A, general driver overhead etc. Machine A will be a real-time system. But to support these tests, I need a separate machine that can bounce back messages and in other ways add network stimuli to the tested system. This separate machine is Machine B in the picture below and is what this question is about.
My problem
I want to develop an application that can receive and return these messages with as consistent (and preferably low) latency as possible. I'm hoping to get latencies that are consistent within a few microseconds at least. For simplicity, I'd like to do this on a general purpose OS like Windows or Linux but I'm open for other suggestions. There will be no other load (CPU or otherwise) on the machine besides the operating system and my test application.
I've thought of the following approaches:
A normal application running in user space with a high priority
A thread running in kernel space to avoid the userspace/kernelspace transitions
An of-the-shelf device that already does this (I haven't found one though)
Questions
Are there any other approaches or perhaps frameworks that already does this? What else do I need to think of to gain a consistent and low latency? What approach is recommended?
You mentioned that you want to test the internal performance of Machine A, but "need a separate machine"; yet, you don't want to test network infrastructure performance.
You know much more about your requirements than I do; however, if I was testing network infrastructure in Machine A, I would set up my test like this:
There are couple of reasons for this:
You can use an Ethernet loopback cable to simulate the "pong" function performed by Machine B
Eliminating transit through infrastructure you don't care about is almost always a better solution when measuring performance
If you use this test method, be sure to note these points:
Ethernet performs a signal to noise test on the copper before it sets up a link. If you make your loopback bends too tight, you could introduce more latency if ethernet decides to fall back to a lower speed due to the kinks in the cable. There is no minimum length for copper ethernet cabling.
As you're probably aware, combinations of NICs / driver versions / OS can have a significant affect on intra-host latency. I work for a network equipment manufacturer, and one of the guys in the office used to work as an applications engineer for SolarFlare. He claims that many of the Wall Street trading systems use SolarFlare's NICs due to the low latency SolarFlare engineers their products for; he also said SolarFlare's drivers give you user-space access to the NIC buffers. Caveat: third-hand info, and I cannot verify myself.
If you loop the frames to Machine A, set the source and destination mac-address to the burned-in-address on the NIC
Even if you need to receive a modified "pong" frame from Machine B, you could still use this topology and simply rewrite packet fields on the receive-side of your code in Machine A. Put as many (or few) instrumentation points as you like in Machine A's "modules" to compare frame timestamps.
FYI:
The embedded systems I mentioned in my comments on your question are for measuring latency of network infrastructure, not end hosts. This is the best method I can think of for instrumenting host latency.
As an off the shelf solution, I would suggest taking a look at Solace, Tibco and AMQP. These are all enterprise messaging frameworks used extensively in trading applications. AMQP is open source and capable of handling throughputs of up to 100,000 messages per second. I am not sure of the latencies of other frameworks. There is a Java or C++ implementation of the AMQP message router. The C++ one of course returns higher performance.
Edit I've just heard of a new product called UltraMessaging which can provide 7,000,000 messages per second throughput with Java, C++ or C# clients. Crikey.
Best regards,
I'm looking for a mechanism to use to create a simple many-to-many messaging system to allow Windows applications to communicate on a single machine but across sessions and desktops.
I have the following hard requirements:
Must work across all Windows sessions on a single machine.
Must work on Windows XP and later.
No global configuration required.
No central coordinator/broker/server.
Must not require elevated privileges from the applications.
I do not require guaranteed delivery of messages.
I have looked at many, many options. This is my last-ditch request for ideas.
The following have been rejected for violating one or more of the above requirements:
ZeroMQ: In order to do many-to-many messaging a central broker is required.
Named pipes: Requires a central server to receive messages and forward them on.
Multicast sockets: Requires a properly configured network card with a valid IP address, i.e. a global configuration.
Shared Memory Queue: To create shared memory in the global namespace requires elevated privileges.
Multicast sockets so nearly works. What else can anyone suggest? I'd consider anything from pre-packaged libraries to bare-metal Windows API functionality.
(Edit 27 September) A bit more context:
By 'central coordinator/broker/server', I mean a separate process that must be running at the time that an application tries to send a message. The problem I see with this is that it is impossible to guarantee that this process really will be running when it is needed. Typically a Windows service would be used, but there is no way to guarantee that a particular service will always be started before any user has logged in, or to guarantee that it has not been stopped for some reason. Run on demand introduces a delay when the first message is sent while the service starts, and raises issues with privileges.
Multicast sockets nearly worked because it manages to avoid completely the need for a central coordinator process and does not require elevated privileges from the applications sending or receiving multicast packets. But you have to have a configured IP address - you can't do multicast on the loopback interface (even though multicast with TTL=0 on a configured NIC behaves as one would expect of loopback multicast) - and that is the deal-breaker.
Maybe I am completely misunderstanding the problem, especially the "no central broker", but have you considered something based on tuple spaces?
--
After the comments exchange, please consider the following as my "definitive" answer, then:
Use a file-based solution, and host the directory tree on a Ramdisk to insure good performance.
I'd also suggest to have a look at the following StackOverflow discussion (even if it's Java based) for possible pointers to how to manage locking and transactions on the filesystem.
This one (.NET based) may be of help, too.
How about UDP broadcasting?
Couldn't you use a localhost socket ?
/Tony
In the end I decided that one of the hard requirements had to go, as the problem could not be solved in any reasonable way as originally stated.
My final solution is a Windows service running a named pipe server. Any application or service can connect to an instance of the pipe and send messages. Any message received by the server is echoed to all pipe instances.
I really liked p.marino's answer, but in the end it looked like a lot of complexity for what is really a very basic piece of functionality.
The other possibility that appealed to me, though again it fell on the complexity hurdle, was to write a kernel driver to manage the multicasting. There would have been several mechanisms possible in this case, but the overhead of writing a bug-free kernel driver was just too high.
My son has a MacOS 9 box to which he is sending remote AppleEvents from his Leopard-based MacBook. Is there any way, programmatically, that I can send remote AppleEvents via TCP/IP from my Windows 7 Toshiba?
If it helps, apple events are sent on port 3031 via TCP/UDP.
From the high level, there are four pieces to apple events:
The data aggregation API (data requests are put into an opaque in memory structure). This API as it stands was wordy and painful to use. Thank goodness you have access to languages that have better data aggregation tools
Conversion/serialization - the opaque data structure is turned into something that can be serialized and transported to another process and for same machine events, this may be a null serialization
Transport the data is transported from one process to another. Single machine is probably just enqueuing a copy of the data. Remote machine is transport over a network protocol, which could be TCP/IP (but it works with AppleTalk as well) and may require authentication.
Deserialization/Conversion
You will most likely need to do steps 2, 3, and 4. If you don't care about getting any information back, you can skip 4, since one of the flags in a sent event is "no reply".
There are a relatively small number of types in the AE data model. I would write code on your OS X machine to send each and every type and reverse engineer the packets when they're sent. To speed up the process you might want to use appscript, on the OS X machine which will let you send events from Ruby, Objective C, or Python.
Sniff the packets between the MacBook and the MacOS 9 box using something like tcpdump or Wireshark. This will tell you what an AppleEvent looks like on the wire.
Then replicate those packets using your programming environment of choice on Windows.
I suggest wrapping up the code that you write into a library that you can reuse in other applications.
Good luck - this might be quite tricky!!
if you're talking about growl notification, there are libraries to use that. for example, here is the growl library for ruby