FIX : Custom messages and fields

 Defining custom FIX protocol messages and custom fields involves extending the standard FIX protocol with your own message types and fields. These customizations are often necessary to support specific business requirements that are not covered by the standard FIX specification.

Here’s a detailed guide on how to define both custom messages and fields in the FIX protocol:

---

1. Defining Custom FIX Protocol Fields

Steps to Define Custom Fields:

1. Choose a Custom Tag Number:

   • The FIX protocol assigns tag numbers to fields, with the range 5000 and above typically being used for custom or proprietary fields.
   • Ensure that the tag number you choose does not conflict with the standard FIX field tags (i.e., 1–4999).

2. Define the Field Name and Description:

   • Field Name: A descriptive name for the field (e.g., CustomOrderID, TraderNote).
   • Tag Number: The number associated with the custom field (e.g., 5500).
   • Data Type: Specify the data type of the field (e.g., String, Integer, Date).
   • Field Description: Clearly describe the purpose of the field.

3. Example Custom Field Definition:

   • Tag: 5500
   • Name: CustomOrderID
   • Type: String
   • Description: A unique identifier for the custom order used internally by the trading system.

Example of Custom Field in a FIX Message:

8=FIX.4.2|9=74|35=D|49=SenderCompID|56=TargetCompID|34=123|5500=OrderABC123|10=154|

Here, the custom field 5500 (CustomOrderID) is sent with the value OrderABC123.

---

2. Defining Custom FIX Protocol Messages

Steps to Define Custom Messages:

1. Define a New Message Type:

   • Each FIX message consists of a set of fields (tags) and has a Message Type identified by a specific MsgType. To create a custom message, you need to assign a new MsgType identifier.
   • Custom message types are typically assigned tag numbers in the range of Z to AZ or from the extended custom tag range (e.g., U1, U2).

2. Create a Message Definition:

   • MsgType: This is the unique identifier for your custom message.
   • Fields: Define the tags and fields that make up your custom message. These can include both standard and custom fields.
   • Sequence and Structure: Define the order in which fields will appear in the message.

3. Define the Message Description and Usage:

   • Message Name: A meaningful name for the custom message (e.g., CustomOrderMessage).
   • Purpose: Describe the purpose of the custom message.
   • Tags/Fields: List the tags and their corresponding fields used in the message.

Example Custom Message Definition:

• MsgType: U1 (custom message type)
• Message Name: CustomOrderMessage
• Tags/Fields:
  • 35=U1 (indicating the custom message type)
  • 5500=OrderABC123 (custom field for order ID)
  • 53=1 (standard FIX field for order side, e.g., buy/sell)
  • 54=1 (standard FIX field for quantity)
  • 38=1000 (standard FIX field for quantity of the order)

---

3. Example of Custom FIX Message Using Custom Fields:

Here’s an example of how you might send a custom message with a custom field in a FIX message:

8=FIX.4.2|9=105|35=U1|49=SenderCompID|56=TargetCompID|34=123|5500=OrderABC123|53=1|54=1|38=1000|10=154|

Explanation:

• 35=U1: This indicates a custom message type (U1).
• 5500=OrderABC123: This is the custom field CustomOrderID with the value OrderABC123.
• 53=1: This is the standard Side field, where 1 might mean a buy order.
• 54=1: This represents the quantity field, here with a value of 1000.
• 38=1000: This is the standard Quantity field in FIX, indicating the size of the order.

4. Implementation and Configuration

After defining your custom messages and fields, you will need to:

1. Update FIX Engine Configuration:

   • Ensure that the FIX engine or parser you are using understands your custom tags and message types.
   • This could mean updating the FIX engine’s configuration files to include the new message types and custom fields.

2. Custom Message Parsing Logic:

   • You may need to write custom parsers or message handlers to interpret your custom messages and fields. Ensure that both encoding and decoding functions support your custom message structure.

3. Communication with Counterparties:

   • When using custom fields and messages, ensure that both your side and your counterparties agree on the structure, tags, and message types. This avoids potential issues in message interpretation.
   • Document the custom message types and field definitions and share them with anyone who needs to communicate with your system via FIX.

---

5. Example of Full Process:

1. Define Custom Field:

• Tag: 5500
• Name: CustomOrderID
• Type: String
• Description: Internal unique identifier for orders.

2. Define Custom Message:

• MsgType: U1
• Name: CustomOrderMessage
• Fields:
  • 5500=OrderABC123
  • 53=1 (Buy)
  • 54=1 (Quantity)
  • 38=1000

3. Send Message:

8=FIX.4.2|9=105|35=U1|49=SenderCompID|56=TargetCompID|34=123|5500=OrderABC123|53=1|54=1|38=1000|10=154|

By following these steps, you can successfully define and implement custom FIX protocol fields and messages that are specific to your application’s needs.

Misc Questions

 Misc Interview Questions

Size of shared_ptr

The size of std::shared_ptr is typically 16 bytes or more on a 64-bit system.

The size consists of an 8-byte pointer to the object and 8+ bytes for the control block that handles reference counting.

The actual size can vary depending on the platform, architecture, and standard library implementation, so you can use sizeof to check it for your environment.

Diamond problem

The diamond problem in C++ (and other object-oriented languages that support multiple inheritance) refers to an ambiguity that arises when a class inherits from two classes that both inherit from the same base class. This situation can cause issues with inheritance and method resolution, specifically when the derived class is unsure which path to take to access the base class's methods or members.

To solve the diamond problem, C++ introduces virtual inheritance. Virtual inheritance ensures that the base class is shared between all the derived classes.

what is array decay in C++

Array decay in C++ refers to the process by which an array is automatically converted to a pointer when passed to a function. This occurs because, in most contexts, the name of an array is interpreted as a pointer to its first element, which causes the loss of the array's size and type information.

Key Points About Array Decay:

1. Array to Pointer Conversion: When you pass an array to a function, it decays into a pointer to the first element of the array. This means the function only receives a pointer, and it no longer has access to the full array's size or type.
2. Loss of Array Size Information: When an array decays into a pointer, the size of the array is lost. The function receiving the array will not know how many elements the array has. This is why, when passing arrays to functions, it's common to also pass the array's size as a separate argument.

To prevent problems from array decay, you can use alternatives like std::array or std::vector, which retain size information and provide safer, more flexible handling of arrays.

Key Differences Between Abstract Class and Interface

Feature	Abstract Class	Interface
Instantiation	Cannot be instantiated directly.	Cannot be instantiated directly.
Methods	Can have both abstract and concrete methods.	Can only have abstract methods (except default and static methods).
Constructor	Can have constructors.	Cannot have constructors.
Fields	Can have instance variables (fields).	Can only have public static final variables (constants).
Inheritance	A class can extend only one abstract class.	A class can implement multiple interfaces.
Access Modifiers	Can have any access modifiers for methods and fields.	All methods in an interface are implicitly public, and they cannot have other access modifiers.
Default Methods	Cannot have default methods.	Can have default methods (Java 8+).
Purpose	Used when classes share common functionality but might not have a strict contract.	Used to define a contract or capability that classes should adhere to.
Multiple Inheritance	No multiple inheritance (one class only).	Supports multiple inheritance (a class can implement multiple interfaces).

REST (Representational State Transfer Application Programming Interface)

Stateless means that each request from the client to the server must contain all the information the server needs to fulfill the request. The server does not store any state about the client between requests. Each request is independent.

HTTP Methods

REST APIs commonly use standard HTTP methods (also called verbs) to perform operations on resources:

GET: Retrieve data from the server. For example, GET /users might fetch all users.

POST: Create a new resource on the server. For example, POST /users might create a new user.

PUT: Update an existing resource. For example, PUT /users/123 might update the user with ID 123.

DELETE: Delete a resource. For example, DELETE /users/123 might delete the user with ID 123.

PATCH: Partially update a resource.

HTTP Status Codes

REST APIs use HTTP status codes to indicate the outcome of the request:

200 OK: The request was successful, and the server has responded with the requested data.

201 Created: The request was successful, and a new resource was created.

400 Bad Request: The server could not understand the request, often due to malformed syntax.

404 Not Found: The resource was not found.

500 Internal Server Error: The server encountered an error while processing the request.

CRUD Operations

REST APIs typically align with the CRUD operations:

Create (POST)

Read (GET)

Update (PUT or PATCH)

Delete (DELETE)

Idempotency

RESTful APIs emphasize idempotency in certain operations. This means that making multiple identical requests should have the same effect as making a single request.

For example, a GET request is idempotent because it will always return the same data.

A DELETE request is also typically idempotent, as deleting a resource multiple times will have the same result: the resource will be gone.

STUB, MOCK or FAKE

Stub: If you’re testing a service that calls an external API, and you want to simulate a successful response from that API, you’d use a stub.

Mock: If you’re testing the interaction between a service and a logging mechanism, and you want to assert that the log method was called with the correct parameters, you’d use a mock.

Fake: If you’re testing a database-driven application and don’t want to rely on a real database, you might use a fake in-memory database.

Some C++ process is running slow - how would you go about investigating

To investigate why a C++ process is running slow, you should:

1. Profile the application using tools like gprof, perf, or Valgrind to find bottlenecks.
2. Analyze algorithms for inefficiency and optimize them.
3. Check for memory leaks or excessive memory usage using profiling tools.
4. Investigate multi-threading issues (e.g., thread contention, lock contention).
5. Look for disk or network I/O issues.
6. Use compiler optimizations and review the code for any unnecessary copies or suboptimal code paths.

Possible Outcomes When There's a Connection Problem:

• Connection Failure: The connection cannot be established or is refused (e.g., server unreachable, port closed).
• Packet Loss: Lost packets trigger retransmissions, slowing down the connection.
• Timeouts: If acknowledgments aren't received within the timeout period, retransmissions are attempted. Multiple timeouts can lead to connection termination.
• Congestion Control: TCP reduces the transmission rate to avoid congestion, which can cause slowdowns.
• Connection Reset: A reset is initiated due to a forced termination or unexpected error.
• Half-Open Connections: Inconsistent connection states when one side terminates while the other side is unaware.
• Firewall/NAT Issues: Network security devices can block or drop TCP packets, resulting in connection issues.

Git and Github Differences:

Git	GitHub
A version control system used to manage source code history.	A platform/hosting service built around Git to store and manage Git repositories online.
CLI-based (command-line interface) tool.	Web-based platform with a GUI for repository management and collaboration.
Git is used locally on your computer to track changes and manage code.	GitHub allows you to host repositories and collaborate with others remotely.
Focuses on version control and local repository management.	Focuses on collaboration, project management, and hosting Git repositories in the cloud.

In a typical workflow:

• Git is used to create and manage repositories on your local machine, commit changes, and track history.
• GitHub is used to store the remote version of your repositories, collaborate with others, and share code. You push and pull changes to and from GitHub using Git commands.

Virtual constructor

 A virtual constructor is not a concept that is explicitly supported by C++ in the same way as other special functions like destructors, copy constructors, or constructors. However, the term virtual constructor is often used informally to refer to a design pattern that mimics the behavior of creating objects via polymorphism or inheritance, as constructors themselves cannot be virtual in C++. The idea behind a "virtual constructor" is to create an object using polymorphism, where you can instantiate an object of a derived class based on a runtime decision, but in a way that still respects object-oriented principles.

Why Can't Constructors Be Virtual in C++?

Constructors cannot be virtual in C++ because the constructor of a class is called when an object is created, and the type of the object (its class) is already determined at compile-time. Virtual functions rely on the dynamic dispatch mechanism, which works based on the actual type of the object at runtime. However, the constructor is executed before the type of the object can be known, so a constructor cannot be virtual.

Simulating Virtual Constructors (Design Pattern)

Although constructors themselves cannot be virtual, we can simulate the behavior of a virtual constructor using a factory method or clone pattern. These patterns allow for creating objects dynamically at runtime based on polymorphism and inheritance, mimicking the behavior of a "virtual constructor."

Factory Method Pattern (Virtual Constructor Simulation)

The Factory Method Pattern involves creating a static method or function that is responsible for creating and returning instances of objects, usually via polymorphism. This pattern allows you to decide at runtime which object to create without directly invoking a constructor.

Example:

cpp
#include <iostream>
#include <memory>

class Product {
public:
    virtual void use() = 0; // Pure virtual method

    // Virtual constructor-like method (factory)
    static std::unique_ptr<Product> createProduct(int type);
};

class ConcreteProductA : public Product {
public:
    void use() override {
        std::cout << "Using ConcreteProductA\n";
    }
};

class ConcreteProductB : public Product {
public:
    void use() override {
        std::cout << "Using ConcreteProductB\n";
    }
};

// Factory method to simulate virtual constructor
std::unique_ptr<Product> Product::createProduct(int type) {
    if (type == 1) {
        return std::make_unique<ConcreteProductA>();
    } else if (type == 2) {
        return std::make_unique<ConcreteProductB>();
    } else {
        return nullptr;  // Return null if no valid type
    }
}

int main() {
    int productType = 1;  // Simulate runtime decision
    auto product = Product::createProduct(productType);  // Virtual constructor simulation

    if (product) {
        product->use();  // Use the created product
    }

    return 0;
}

In this example:

• We have a Product base class with a pure virtual method use().
• The ConcreteProductA and ConcreteProductB classes are derived from Product and implement the use() method.
• The createProduct() static method in Product acts like a "virtual constructor" by deciding at runtime which type of Product to create (either ConcreteProductA or ConcreteProductB), based on the type passed in.

This method allows you to decide at runtime which type of object to instantiate, based on polymorphism, and hence simulates the behavior of a virtual constructor.

Clone Pattern

Another approach to simulating a virtual constructor is by using the clone pattern. The clone pattern involves creating a clone() method in the base class, which returns a copy of the object, typically via polymorphism.

Example:

cpp
#include <iostream>
#include <memory>

class Product {
public:
    virtual void use() = 0;
    virtual std::unique_ptr<Product> clone() const = 0;  // Clone method simulating virtual constructor
    virtual ~Product() = default;  // Virtual destructor
};

class ConcreteProductA : public Product {
public:
    void use() override {
        std::cout << "Using ConcreteProductA\n";
    }

    std::unique_ptr<Product> clone() const override {
        return std::make_unique<ConcreteProductA>(*this);  // Return a clone of the object
    }
};

class ConcreteProductB : public Product {
public:
    void use() override {
        std::cout << "Using ConcreteProductB\n";
    }

    std::unique_ptr<Product> clone() const override {
        return std::make_unique<ConcreteProductB>(*this);  // Return a clone of the object
    }
};

int main() {
    ConcreteProductA prodA;
    auto prodA_clone = prodA.clone();  // Cloning the product A

    prodA_clone->use();  // Using the cloned object

    ConcreteProductB prodB;
    auto prodB_clone = prodB.clone();  // Cloning the product B

    prodB_clone->use();  // Using the cloned object

    return 0;
}

In this case:

• Each class (ConcreteProductA, ConcreteProductB) implements a clone() method that creates and returns a copy of the object.
• The clone() method provides a way to duplicate objects without directly invoking constructors, which can be useful when you need to create objects dynamically or copy them polymorphically.

Conclusion

• Virtual constructors aren't a built-in feature of C++, but you can simulate the effect of virtual constructors using design patterns like Factory Methods and Clone Patterns.
• These patterns allow you to decide which type of object to instantiate at runtime, and can help achieve polymorphic object creation in scenarios where constructors cannot be virtual.

What would you do when one process on your linux is deadlocked

 When one of your processes on Linux is deadlocked, it means that the process (or processes) is stuck in a state where it is waiting for resources held by another process, which is itself waiting for resources that the first process holds. This typically results in a situation where neither process can proceed, causing a deadlock. Deadlocks are problematic because they lead to the system hanging or experiencing reduced performance.

Here are the steps you can take to deal with a deadlocked process on a Linux system:

1. Identify the Deadlocked Process

The first step is to identify the deadlocked process. There are several ways to check which process is deadlocked:

• Use ps or top to check process state:

  • ps aux | grep D – The D state indicates that a process is in uninterruptible sleep (waiting on I/O or waiting for some resource).
  • top – In the top command, you can look for processes that are in the "D" state, which indicates they are waiting for resources.

• Use lsof (List Open Files) to find blocked processes:

  • lsof | grep <PID> – This shows which files or resources a process has locked, which might help you identify the resources involved in the deadlock.

• Use strace to trace the system calls:

  • You can use strace on a process to see where it’s stuck. This will show the system calls the process is making and might indicate where it’s blocked. For example:

    bash
    strace -p <pid>
    

    This will show you the system calls the process is making, which might provide insights into what resources it is waiting for.

2. Examine Logs for Deadlock Evidence

Look at the system logs for any messages about deadlocks or resource contention. You can check:

• System log (/var/log/syslog or /var/log/messages)
• Kernel log (dmesg)

These logs might provide clues, such as warnings or errors related to a deadlock.

bash
dmesg | grep -i deadlock

3. Check for Resource Locks

If a process is deadlocked due to a resource lock (e.g., a file or database), you can use tools like:

• lsof (List Open Files): To check which files are being held by processes. It might help identify which files are involved in the deadlock.

  bash
  lsof | grep <resource>
  

• Database Locks: If the process is interacting with a database (like MySQL, PostgreSQL, etc.), you may need to use the database's tools to inspect locks. For example:

  • MySQL: Use SHOW ENGINE INNODB STATUS to view any deadlocks within the InnoDB storage engine.
  • PostgreSQL: Use SELECT * FROM pg_locks; to see lock information.

4. Kill the Deadlocked Process

Once you identify the deadlocked process, you may need to terminate it to resolve the deadlock. You can do this by:

• Using the kill command:

  bash
  kill -9 <PID>
  

  This sends a SIGKILL signal to forcefully terminate the process. While this is effective, it doesn't allow the process to clean up resources, so use it carefully.

• If you want to try to terminate the process gracefully, you can send a SIGTERM signal:

  bash
  kill -15 <PID>
  

  This gives the process a chance to terminate gracefully, but it may not work if the process is stuck in an uninterruptible state.

5. Investigate and Prevent Future Deadlocks

Once the deadlock is resolved, it's essential to investigate why the deadlock happened and take steps to prevent it from happening again:

• Analyze Code for Deadlock Conditions: If you have control over the application or code, you should carefully analyze the code for deadlock conditions, such as improper locking order or unintentional circular dependencies between resources.

• Timeouts and Watchdogs: Implement timeouts in critical sections or database transactions to avoid indefinite waiting. A watchdog process can help detect long-running processes and intervene before a deadlock happens.

• Concurrency Patterns: Use modern concurrency techniques like lock hierarchies, lock-free programming, or using higher-level libraries (like std::mutex or std::lock in C++) to help prevent deadlocks.

• Resource Management Tools: If the deadlock involves file or database locks, you might need to adjust how resources are acquired and released to avoid blocking other processes.

6. Reboot the System (if necessary)

If a deadlock involves system-wide resources or if multiple processes are deadlocked and terminating the process doesn’t help, rebooting the system might be required to restore the system to a stable state.

• Rebooting will reset all processes and clear any lingering locks or states that could be contributing to the deadlock.

  bash
  sudo reboot
  

7. Monitor System for Future Deadlocks

After addressing the immediate deadlock, you should implement monitoring tools and logs to watch for potential deadlocks in the future:

• Use System Monitoring Tools like top, htop, or glances to monitor process states in real-time.
• Set up Alerts for unresponsive processes or high resource usage that might indicate deadlocks.

---

Summary:

1. Identify the deadlocked process using tools like ps, top, or lsof.
2. Examine logs (dmesg, /var/log/syslog) for any deadlock-related messages.
3. Check for resource locks (e.g., using lsof or database tools).
4. Kill the deadlocked process using kill -9 or kill -15.
5. Investigate the root cause of the deadlock and refactor code to avoid future occurrences.
6. Reboot the system if needed, especially for system-wide deadlocks.
7. Set up monitoring to detect and alert for future deadlocks.

By following these steps, you can resolve the deadlock, analyze the root cause, and implement measures to prevent deadlocks from happening in the future.