5df588674e
So, let's get into it. First, we are straying from the in-memory ideation of storing all our pcap chunks in the memory I fear that we might bottle up the ram if we depend solely on it. So, i've made things default to sqlite flatfile, with the option for both remote and in memory This way, dependant on the users needs, they can use a different implementation. That's why the creation of a great deal of files and an entire new directory space I've almost finished implementing the database system into itself, but I want the DB system to be largely independent of the rest of the system. Because, you know me, I am a fan of encapsulation. and I like making software coded to be independent. Yes, if the rest of the system isn't working, the database has nothing to docker but at least it makes the system more robust, if even a major system can collapse, and the system as a whole remains functional. Philisophically, I find this is largely lacking in modern software, and I believe that these practices will see the protohandler performing much better than we would expect Since this system as a whole will be independent of the main NETRAVE system, it opens the door for further expanding, or perhaps even completely repurposing this protocol going forward.
19 lines
643 B
Ruby
19 lines
643 B
Ruby
#!/usr/bin/env ruby
|
|
|
|
# frozen_string_literal: true
|
|
|
|
require_relative 'config_manager'
|
|
|
|
# Initialize the ConfigManager
|
|
config = ProtoConfig::ConfigManager.instance
|
|
|
|
# Your logic to start the Protocol Handler goes here
|
|
# For example, you could initialize your server with the IP and port from the config
|
|
# Or pass the recently_connected_time to your connection handling logic
|
|
|
|
puts "NETRAVE Packet Exchange Protocol Handler (NPEPH) is starting..."
|
|
puts "Listening on #{config.listen_ip}:#{config.listen_port}"
|
|
puts "Recently connected time threshold: #{config.recently_connected_time} seconds"
|
|
|
|
# Your server initialization and start logic here
|