I’m working on a network simulation project using OMNeT++ version 4.6 with the INET framework. My setup involves a machine learning model built in Python that needs to communicate with the simulation while it’s running.
Here’s what I need to accomplish: The OMNeT++ simulation calculates network metrics like signal-to-noise ratios and tracks where mobile devices are positioned. This information must be transferred to my Python ML algorithm for real-time training. After processing this data, the Python script generates control commands to optimize network performance, which then need to be sent back to the running simulation.
I’m looking for practical approaches to establish this bidirectional communication between these two separate processes during execution. What methods or libraries would work best for this kind of runtime integration?
Named pipes work great for this. Way simpler than sockets but still handle two-way communication perfectly. Set up a named pipe in your OMNeT++ sim to write metric data (text or binary). Python reads from that same pipe continuously and feeds your ML model. For the return path, create a second pipe where Python writes control commands that OMNeT++ picks up during its event loop. Best part is synchronization - you control exactly when data flows without messy threading. In OMNeT++, put pipe operations in initialize() and finish(), then do periodic writes in handleMessage(). Python handles it with basic file operations. I’ve had way better luck with this than network solutions when everything runs on one machine. Performance is solid since there’s no network overhead. Just watch out for pipe blocking - use O_NONBLOCK flags so your sim doesn’t freeze when Python gets stuck training.
I’ve hit this same integration problem before. Here’s what actually works in production.
Start with TCP sockets - it’s the easiest route. Set up a socket server in your OMNeT++ module that pushes network metrics as JSON. Your Python script connects as a client, runs the ML model on the data, then sends optimization commands back through the same connection.
ZeroMQ is another solid option I’ve used. Way more robust than raw sockets and handles messaging patterns cleanly. You get buffering built-in and can swap communication patterns later without much hassle.
For OMNeT++, create a custom module inheriting from cSimpleModule. Override handleMessage() to grab your metrics and send them out periodically. Use non-blocking socket ops or you’ll freeze the simulation.
Python side - keep ML processing in its own thread, separate from socket handling. Prevents blocking when your model’s crunching numbers.
Heads up though - OMNeT++ 4.6 is ancient. If you can upgrade, newer versions have way better integration options.
I’d go TCP sockets first since debugging is simpler. Get basic communication working, then move to ZeroMQ if you need the extra features.
I’ve been working with real-time coupling scenarios like this for years. Redis as a message broker between OMNeT++ and Python works great - it’s lightweight, handles concurrent access well, and you can add pub/sub later if needed. Set up a custom scheduler in OMNeT++ that grabs your SNR and position data periodically, then pushes it to Redis keys or lists. Your Python ML component subscribes to these streams and processes them async. When the model generates control commands, write them back to Redis channels that OMNeT++ watches. The best part? Your simulation won’t block waiting for ML processing, and you can easily add more Python workers if you need to scale. Redis keeps data around briefly too, so you won’t lose anything if a process crashes. For OMNeT++, compile against hiredis C library and create a connection manager module for Redis operations. Python side is easy - redis-py works great with most ML frameworks. I’ve used this setup in production where timing matters and it’s been solid.
shared memory’s prob the best route. setup a memory mapped file both can access directly - no network delays or pipe overhead. let omnet++ dump metrics to certain memory spots, while python reads straight from there. add semaphores for sync to avoid race conditions. beats tcp for tight integration.
