Question background:
My MFC CAsyncSocket-based socket code has worked fine in the lab for a long time, until it didn't (see how to determine socket interface type). It's design was based on the Microsoft Docs sample code which sequentially walks through a linked-list of socket interfaces keyed on socket family (like, AF_INET, AF_INET6, etc). With Remy Lebeau's answer to my question, I am now able to list the details of any interface my users might encounter. But as Remy points out there are MANY MANY interfaces out there. "Out there" is quite broad for me since my architecture is that of a dApp (aka, no servers), meaning I won't know my user's precise interface environment in advance. That leaves me with an interface selection design problem.
My question:
How do I select an interface when I don't know the interface environment of virtually all my potential users? There are potential indicators like an interface's Description or Friendly Name I could use to narrow down my selection resolving code. There is an interface structure member called IfType defined in ipifcons.h which contains 281 types. I could perhaps choose a subset from these. There is also a GetBestInterface function, but I don't know if that would work all the time or what its intention is.
I am looking for some guidance on this issue.
Related
I know, the use case might be specific but more and more stuff in all industry sectors is digitalized—and so is the communication between different departments which sometimes talk in very different languages. I searched the internet, but I wasn't able to find a clear answer (either I didn't find the right search phrases or the internet itself just doesn't know).
Here's my scenario: I'm working with several departments which work with diagrams (for example a lighting setup). This diagram solves different purposes:
which devices are used?
where are they placed?
where are they pointing?
how are they configured (e.g. exposure)?
They tend to export their finalized diagram as either an image or a PDF— which is fine if you want to print it out but considerably less helpful if another department (mine) has to work with the raw information. That's where I wondered if there's some kind of industry standard (SVG, XML, JSON, etc.) which is both supported by the programs these departments used and can be interpreted by some sort of programming language. Do you know anything like that?
Thanks in advance!
I was wondering if I can implement bi-directional communication channel between 2 kext modules using sockets under the domain PF_SYSTEM. this method mostly used to communicate between driver and user-space agent..
In my particular case I've got one module based on IOKit and the other which is simple kernel module with start and stop callback functions and I'd like to pass some small messages between them..
Do you think this approach is suitable for my needs or there's other preferable way (shared memory ? mach ports ? )
EDIT, after digging a little deeper, maybe there's an option to export an API from one driver to the other by modifying the client driver plist file as follows.. is it possible ?
<key>OSBundleLibraries</key>
<dict>
<key>com.driver.server_driver</key>
<string>1</string>
This however, doesn't work because when i try to manually load the client driver after the server driver already loaded (visible from kextstat), I get the No kexts found for these libraries error.
Using messaging techniques normally used for IPC for communicationg between kernel extensions is unusual, as it's a lot more complex than taking advantage of the fact that they're running in the same address space anyway. I covered some of the details of this latter approach in my answer to your other question which you've obviously already seen, but I'm linking to for the benefit of others in a similar situation.
To answer your question: I suspect both ends of a system socket being in the kernel is probably not very well tested, and you could run into bugs in the kernel. The in-kernel public socket KPI is also quite fiddly: getting the buffering right is tricky, so I'd only use sockets if I absolutely had to, and it clearly isn't here.
My gut instinct is that Mach messaging would work more reliably and require less code, but again I think it would be quite unusual to use it in this way.
It's hard to give useful advice on exactly what you should do, as we don't know the reasons for the separation into 2 kexts, what their relationship is, what kind of communication is required, etc. There are many possible ways on how to exchange information, but whether they are a good idea will depend on the details of the project. (This sort of question isn't really suitable to Stack Overflow's format - this is the sort of problem for which a company will bring in an expert to consult. For a private project, you might have more luck on the Software Engineering Stack Exchange Site, where this sort of question is on-topic, although I'm not sure you'll get a good/useful answer. For a private project it's probably best you keep it simple and maybe combine the 2 kexts into one?)
I am looking at linking a few applications together (all written in different languages like C#, C++, Python) and I am not sure how to go about it.
What I mean by linking? The system I am working on consists of small programs each responsible for a particular processing task. I need to be able to transfer a data set from one application to another easily (the data set in question is not huge, probably a few megabytes) and I also need some form of way to control the current state of the operation (This is where a client-server model rings a bell)
It seems like sockets or maybe SOAP would be a universal solution but just wanted to get some opinions as to what people think about this subject.
Comments/suggestions will be appreciated, thanks!
I personally take a liking towards ØMQ. It's a library that has a familiar BSD-sockets-like interface for passing messages, but you'll find it implements interesting patterns for distributing tasks.
It sounds like you want to arrange several processes in a pipeline. ØMQ allows you to do that using push and poll sockets. (And afterwards, you'll find it's even possible to scale up across multiple processes and machines with little effort.) Take a look at the guide to get started, and the zmq_socket(3) manpage specifically for how push and pull works.
Bindings are available for all the languages you mention.
As for the contents of the message, ØMQ doesn't concern itself with that, they are just blocks of raw data. You can use any format that suits you, such as JSON, or perhaps Protocol Buffers.
What I'm not sure about is the ‘controlling state’ you mention. Are you interested in, for example, cancelling a job halfway through?
For C# to C# you can use Windows Communication Foundation. You may be able to use it with Python and C++ as well.
You may also want to checkout named pipes.
I would think about moving to a model where you eliminate the issue by having centralized data that all of the applications look at. Keep "one source of the truth" so to speak.
Most outside software has trouble linking against C++ code, due to the name-mangling algorithm it uses for its symbols. For that reason, when interfacing with programs written in other languages, it is often best to declare wrappers to things as extern "C" or inside an extern "C" { block.
I need to be able to transfer a data set from one application to another easily (the data set in question is not huge, probably a few megabytes)
Use the file system.
and I also need some form of way to control the current state of the operation
Again, use the file system. A "current_state.json" file with a JSON serialized object is perfect for multiple languages to work with.
It seems like sockets or maybe SOAP would be a universal solution.
Perhaps. But it's overkill for this kind of thing. Your OS already has all the facilities you need. Just use the file system. It's very simple and very reliable.
There are many ways to do interprocess communication. As you said, sockets may be a universal solution. SOAP, i think, is somewhat an overkill. You may also use mailslots. I wrote C++ application using it a couple of years ago. Named pipes could be also a solution, but if you are coding on Windows, it may be difficult.
In my opinion:
Sockets
Mailslots
Are the best candidates.
i have never done embedded (i dont know if thats what you call this) programming and know nothing about it. my question:
is it possible to have two devices sharing a wireless connection (no internet, just between themselves, perhaps bluetooth, but i dont know what ever is best) ?
is it possible to have one editing a file and the other person editing the same file and they can see changes in real time? sort of like google docs?
does this exist already?
what can i do to get started regarding this kind of programming?
to clarify:
i want two people with iphones or any other hand held device, to be able to edit a text file at the same time and see each other's changes in real-time. how do i do this?
There are a bunch of slightly strange assumptions hidden in your questions. I'll try to unpick them as best as I can.
You've used "embedded" programming in a strange way. Usually this would suggest some kind of low-power devices used in settings without direct user interaction in some sense (e.g. factory controllers, refrigerator controllers, sensor nodes), performing a very specific task, but you've gone on to talk bout people editing files. What exactly would be the user interface here? What would make this embedded programming? I think you need to describe an application before any advice can be offered.
If you actually mean embedded devices, then whether they can connect wirelessly to one another is going to depend on the nature of the device. Similarly, the protocol/technologies involved will depend on the device. Embedded programming tends to be very much device-specific. There certainly exist wireless sensor nodes, for example, that incorporate small radio transceivers for serial comms.
Google docs already exists. Without a clearer problem description it's difficult to say whether what you want exists already or not.
I think you should really figure out exactly what kind of programming it is that you want to do before we can offer points as to how to best get started with it. Maybe look up a definition of "embedded programming" and see how this relates to your goals such that you can reformulate your questions a little more clearly.
I'm not sure how "real time" would fit into this scenario either. This term is used and abused in many ways. Things are only ever real-time with respect to some constraint, usually defined in terms of the application.
(Note: This might have been more appropriate as a comment, but I felt there was too much to respond to in order to sum up within character limits, and I hope correcting some of the confusion constitutes something of an answer, given the limitations of the question).
Two devices can share a connection like this. It's done all the time. There are many many protocols for this. Weather or not it is wired or wireless or uses the Internet doesn't really matter for 90% of this.
This is sort of doable, but not really. You really have a race condition when two people are editing at the same time. This is generally avoidable by locking out small parts of the document at from all but one editor at a time (like only one person being able to edit one cell of a spreadsheet at a time), but this has problems too (like of the one active editor is taking way too long -- this is a problem seen in many source version control systems too).
1 already exists in many many forms. 2 sort of exists in many forms, but the problems I mentioned are impossible to completely overcome.
The way you asked this question leads me to believe that you are very far from being able to do this. In addition, you didn't tell us anything about what you do know how to do. Can you write a simple text editor for an iPhone (or anything else)? Simple text editors from scratch that aren't crappy aren't easy to write.
What you need to do, if you really want to do this, is to come up with a protocol for the two (or more) devices to talk to each other in. To do this it is probably best if you figure out what type of communication is available between the devices and which of those you will use and what features it does not provide that you will need on top.
You could try to send patches of the file (or something similar) between the two devices as edits are made, but then you'll have to decide what to do in the event of a collision (edits near the same place).
Alternately you could have the two devices exchange permission to make edits (like in token ring networks).
You still have a problem if the two devices lose communication with each other during the editing of the file, though. With the token ring type setup you stand the possibility of losing the token and neither being able to automatically recover easily. Whatever you do you end up with the problem of the two ending up with different ideas of the file's contents.
"iphones or any other hand held device" - the technology stack to do that doesn't exist today. You have to co-ordinate between multiple languages and systems. (Okay, maybe you want to write that software, but it's a huge undertaking).
Your best bet would be to create a web page that all of the mobile browsers can work on and save a text file from.
Of course it's possible. Bluetooth does this. Wi-Fi does this if you join an ad-hoc network.
Of course it's possible. Just run the Google Docs server on one of the devices.
It might.
Way too vague.
Looking at Microsoft's Managed Extensibility Framework (MEF) and various IoC containers (such as Unity), I am failing to see when to use one type of solution over the other. More specifically, it seems like MEF handles most IoC type patterns and that an IoC container like Unity would not be as necessary.
Ideally, I would like to see a good use case where an IoC container would be used instead of, or in addition to, MEF.
When boiled down, the main difference is that IoC containers are generally most useful with static dependencies (known at compile-time), and MEF is generally most useful with dynamic dependencies (known only at run-time).
As such, they are both composition engines, but the emphasis is very different for each pattern. Design decisions thus vary wildly, as MEF is optimized around discovery of unknown parts, rather than registrations of known parts.
Think about it this way: if you are developing your entire application, an IoC container is probably best. If you are writing for extensibility, such that 3rd-party developers will be extending your system, MEF is probably best.
Also, the article in #Pavel Nikolov's answer provides some great direction (it is written by Glenn Block, MEF's program manager).
I've been using MEF for a while and the key factor for when we use it instead of IOC products is that we regularly have 3-5 implementations of a given interface sitting in our plugins directory at a given time. Which one of those implementations should be used is actually something that can only be decided at runtime.
MEF is good at letting you do just that. Typically, IOC is geared toward making sure you could swap out, for a cononical example, an IUserRepository based on ORM Product 1 for ORM Product 2 at some point in the future. However, most IOC solutions assume that there will only be one IUserRepository in effect at a given time.
If, however, you need to choose one based on the input data for a given page request, IOC containers are typically at a loss.
As an example, we do our permission checking and our validation via MEF plugins for a big web app I've been working on for a while. Using MEF, we can look at when the record's CreatedOn date and go digging for the validation plugin that was actually in effect when the record was created and run the record BOTH through that plugin AND the validator that's currently in effect and compare the record's validity over time.
This kind of power also lets us define fallthrough overrides for plugins. The apps I'm working on are actually the same codebase deployed for 30+ implementations. So, we've typically go looking for plugins by asking for:
An interface implementation that is specific to the current site and the specific record type in question.
An interface implementation that is specific to the current site, but works with any kind of record.
An interface that works for any site and any record.
That lets us bundle a set of default plugins that will kick in, but only if that specific implementation doesn't override it with customer specific rules.
IOC is a great technology, but really seems to be more about making it easy to code to interfaces instead of concrete implementations. However, swapping those implementations out is more of a project shift kind of event in IOC. In MEF, you take the flexibility of interfaces and concrete implementations and make it a runtime decision between many available options.
I am apologizing for being off-topic. I simply wanted to say that there are 2 flaws that render MEF an unnecessary complication:
it is attribute based which doesn't do any good to helping you figuring out why things work as they do. There's no way to get to the details burred in the internals of the framework to see what exactly is going on there. There is no way to get a tracing log or hook up to the resolving mechanisms and handle unresolved situations manually
it doesn't have any troubleshooting mechanism to figure out the reasons for why some parts get rejected. Despite pointing at a failing part it doesn't tell you why that part has failed.
So I am very disappointed with it. I spent too much time fighting windmills trying to bootstrap a few classes instead of working on the real problems. I convinced there is nothing better than the old-school dependency injection technique when you have full control over what is created, when, and can trace anything in the VS debugger. I wish somebody who advocates MEF presented a bunch of good reasons as to why would I choose it over plain DI.
I agree that MEF can be a fully capable IoC framework. In fact I'm writing an application right now based on using MEF for both extensibility and IoC. I took the generic parts of it and made it into a "framework" and open sourced it as its own framework called SoapBox Core in case people want to see how it works.
In particular, take a look at how the Host works if you want to see MEF in action.