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
Related
I am making a CAN simulator for GPS trackers, they only record CAN data and doesn't send ACK. Is it possible to send CAN data with raspberry, using mcp2515/tja1050, without any device on bus that would trigger ACK?
This will usually generate a continuous retransmit.
Some devices have a "one-shot" transmit mode when just sends the CAN frame and does not attempt a retransmission. If you transmitter has this mode you can do what you describe, otherwise you will get a lot of retransmissions.
No it isn't possible, you need at least 2 nodes that are actively participating in the communication. This can however be fixed by just providing another CAN controller on the bus, which doesn't have to do anything intelligent except the ACK part.
For development/debug/test purposes you can however put your own node in "loopback mode", meaning it will speak to itself. Can be handy if you have to proper hardware available yet.
You can try to set the controlmode presume-ack to on.
Assuming you are using the ip command for creating your can sockets that would be something like
ip link set <DEVICE> type can presume-ack on
This will ignore missing ACKs. However I am not sure whether this works with all controllers.
I'm having problems scaling up an application that uses the actor model and zeromq. To put it simply: I'm trying to create thousands of threads that communicate via sockets. Similar to what one would do with a Erlang-type message passing. I'm not doing it for multicore/performance reasons, but because framing it in this way gives me very clean code.
From a philosophical point of view it sounds as if this is what zmq developers would like to achieve, e.g.
http://zeromq.org/whitepapers:multithreading-magic
However, it seems as if there are some practical limitations. At 1024 inproc sockets I start getting the "ZMQError: Too many open files" error. TCP gives me the typical "Assertion failed: fds.size () <= FD_SETSIZE" crash.
Why does inproc sockets have this limit?
To get it to work I've had to group together items to share a socket. Is there a better way?
Is zmq just the wrong tool for this kind of job? i.e. it's still more a network library than an actor message passing library?
ZMQ uses file descriptors as the "resource unit" for inproc connections. There is a limit for file descriptors set by the OS, you should be able to modify that (found several potential avenues for Windows with a quick Google search), though I don't know what the performance impact might be.
It looks like this is related to the ZMQ library using C code that is portable among systems for opening new files, rather than Windows native code that doesn't suffer from this same limitation.
I have a (legacy) specialized packet sniffing application which sniffs the Ethernet using libpcap and analyzes the received data. "The analyzer"
I'm adding another process which reads "data" from a PCI card and I'd like to feed that data into the analyzer. "The sender".
Both the sender and analyzer are on the same host running in different processes.
On the sender side, its easy enough to read the PCI card and send the data over a socket. However, on the receiving side I could either
a) modify the existing libpcap code and set an appropriate filter, or
b) just open and read a socket
Speed and performance is the important parameter. There are several pairs of sender/receiver processes running and the total across all of them is about 1 Gb/s.
Any insight on which method would be faster, more efficient, or "better" ?
Modifying the libpcap receiver code would be pretty messy, but reading other posts, pcap should be using lots of tricks to improve performance (mmap, etc).
(But wouldn't reading a local socket use those same tricks?)
Thanks!
(system environment is Centos 3.16 kernel)
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.
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/