what does id field means? (nf_conntrack struct member) - netfilter

I am studying linux conntrack(command line interface for netfilter connection tracking).
And I have a question. what is id field which is nf_conntrack struct member?
what is that id?
Message id? or Kernel Session Table Entry id?
If both are incorrect, then what is id?
Thanks in advance.

Each unique TCP connection or UDP session (defined by source/dest & ip/port) gets assigned one unique ID.
conntrack --dump conntrack --output extended,id
However as soon as it closed or expires the ID number can be reused. I have seen repeating IDs as close as one minute, so generally speaking the ID is not a good way to identify connections along time.

Related

Unique identifier for all fix messages related to a sinqle request in quickfix

We need to get a unique identifier for all related fix messages in quickfixj.
scenario: if B lies between A and C and forwards fix messages from A to C and vice versa, we need to get a unique Id for all related messages to cache them in B.
Is there a uniqueId for all fix messages as mentioned above? if yes, does getting that unique identifier same (eg: message.getString(int field)) for all message types, or getting it depends on message type?
Do you mean a unique identifier per Order, for example? If yes, then that would be 11/ClOrdID for a NewOrderSingle (and some other message types). But you'll have other identifiers for other message types, e.g. quotes, market data snapshots, ...
There is no global unique identifier per se, so you would need to make one up. For example a concatenation of SenderCompID and MsgSeqNum and SendingTime should be unique. If you are sure that you will not reset the sequence number intra-day you could probably even leave out the SendingTime.

Ruby/Rails: Hashing array of participant phone numbers to uniquely identify a group/MMS text conversation?

While I'm using Ruby/Rails to solve this particular problem, the specific issue is not unique to Ruby.
I'm building an app that can send group/mms messages to multiple people, and then processes those texts when the others reply.
The app will have a different number for each record, and each record can be involved in multiple group conversations.
For example, record_1 can be involved in a conversation with user_1, user_2, but can also be involved in a separate conversation with user_2, user_3, and record_2 can have a separate conversation with user_1, user_2.
When I send a message the fields resemble:
{
from: "1234566789",
to: [
"1111111111",
"2222222222",
...
],
body: "..."
}
Where the from is my app number, and the to [] is an array of phone numbers for everyone else involved in the conversation.
When one of the other participants replies to the group message, I'll get a webhook from my text messaging provider that has the from as that person's phone number and the to [] would include my app number and everyone else's numbers.
The identifier for a conversation is the unique combination of the phone numbers involved.
However, having an array of ["1234567890", "1111111111", "2222222222"] is difficult to work with, and I would like a string representation that I can index in my database and quickly find.
If I have a to: ["1234567890", "1111111111", "2222222222] array of the phone numbers, I'm thinking about using Digest::MD5.hexdigest to.sort.to_s.
This would give me a unique identifier such as 49a5a960c5714c2e29dd1a7e7b950741, that I can index in my DB and use to uniquely reference conversations.
Are there any concerns with using the MD5 hash to solve my specific problem? Anytime I have the same numbers involved in a conversation, I want it to produce the same hash. Does MD5 guarantee the same result given the same ordered input?
Is there another approach to uniquely identify conversations by the participants?
Yes, MD5 does give you that guarantee, unless someone is trying to attack your system. It is possible to create colliding MD5 hashes but they will never happen by accident.
So if in your situation the hash will only ever be benign (i.e. created by your code, not created by someone trying to mount an attack of some kind), then using MD5 is fine.
Or you could switch to using SHA256 instead of MD5 which doesn't have this risk associated with it.

Apple Wallet passes comperation

I have a loyalty programm app where every user can add his loyalty card in Wallet. Each of cards have same passTypeIdentifier and serialNumber but different barcode information. When I already have a card in Wallet and trying to add new card for new user containsPass method of PKPassLibrary returns true. How can I correctly compare these two cards? I can suggest to add field with unique id to backingFields (card number for example), but maybe you have better solution
Your passes should not have the same serial number. From the PassKit Package Format Reference
serialNumber - Serial number that uniquely identifies the pass. No two passes with the same pass type identifier may have the same serial number.
The serial number would typically be the same as the barcode number, or at least related to it in some way.

Synchronizing a current message id in a conversation between Alice and Bob

I'm faced with this situation:
Host A and B are exchanging messages in a conversation through a broker.
When host B receives a messages it sends back a delivery token to Host A so that it can show the user that B has received his messages. This may also happen the other way around.
At any point A or B may be offline and the broker will hold on to the messages until they come online and then deliver them.
Each host stores it's own and the other hosts messages in a database table:
ID | From | To | Msg | Type | Uid
I figured using the naive table primary key id would have been a bad choice to identify the messages (as it's dependent in order of insertion) so I defined a custom unique id field (uid).
My question is:
How can I make sure that the current message id stays synchronized between host A and B so that only one message has that id? So that I can use delivery token id to identify which message was received, and it wouldn't be possible if I had more than one message with the same Id.
If I do this naively incrementing it every time we send/receive a message at first it looks ok:
Host A sends message with ID 1 and increases it's current ID to 2
Host B receives a message and increases it's current ID to 2
Host B sends message with ID 2 and increases it's current ID to 3
Host A receives message and increases it's current ID to 3
...
But it may very easily break:
Host A sends message with ID 1 and increases it's current ID to 2
Host B sends a message (before receiving the previous one) with ID 1
clash.. two messages with ID 1 received by both hosts
I thought of generating a large UUID every time (with extremely low chance of collision) but it introduces a large overhead as every message would need both to carry and store one.
Unfortunately any solution regarding the broker is not viable because I can't touch the code of the broker.
This is a typical problem of Distributed Systems (class exercise?). I suppose you are trying to keep the same ID in order to determine an absolute order among all messages exchanged between Alice and Bob. If this is not the case, the solution provided in the comment by john1020 should be enough. Other possibility is to have ID stored in one node that can be accessed by both A and B and a distributed locks mechanism synchronizes access. In that way, you always define an order even in face of collisions. But this is not always possible and sometimes not efficient.
Unfortunately, there is no way of keeping an absolute order (except having that unique counter with distributed locks). If you have one ID that can be modified by both A and B, you will have a problem of eventual consistency and risk of collisions. A collision is basically the problem you described.
Now, imagine both Bob and Alice send a message at the same time, both set ID in 2. What would be the order in which you would store the messages? Actually it doesn't matter, it's like the situation when two people spoke at the phone at the same time. There is a collision.
However, what is interesting is to identify messages that actually have a sequence or cause-effect: so you could keep an order between messages that are caused by other messages: Bob invites Alice to dance and Alice says yes, two messages with an order.
For keeping such order you can apply some techniques like vector clocks (based on a Leslie Lamport's timestamps vector algorithm): https://en.wikipedia.org/wiki/Vector_clock . You can also read about AWS' DynamoDB: http://the-paper-trail.org/blog/consistency-and-availability-in-amazons-dynamo/
Also you can use the same mechanism Cassandra uses for distributed counters. This is a nice description: http://www.datastax.com/wp-content/uploads/2011/07/cassandra_sf_counters.pdf

Reading SNMP Object index of type IPAddress

In a simple SNMP table like mib-2.interfaces.ifTable, ifIndex is the index for the table, so you read ifIndex.1 (i.e. read value from direct child nodes of ifIndex) to get the index for the first row of the table. Simple enough.
But it's not as obvious with something like mib-2.ip.ipRouteTable. In that case ipRouteIfIndex is the index column. It's defined as INTEGER just like ifIndex was. However, you can't read the direct child nodes (i.e. ifIndex.0 is a direct child), but instead need to read ifIndex.0.0.0.0 to get to the value. So how does one know how to find the value when it's not a direct child of the index column?
There is some concept that I'm not understanding. (Probably having to do with the fact that SNMP objects are delimited by . but so are IP addresses, and I can't tell how to recognize the difference).
Note that you have a table with multiple indices in this particular case.
The fact is that you cannot directly read the table entries with snmp-get service, since the index is dynamic (and, as a consequence, the OID address). But you can discover the values with snmp-get-next (v1) and snmp-get-bulk (v2) services.
For example, you can read the indices (and store them for querying table items later) or directly read the items of the table :
you ask snmp-get-next for IP-MIB::ipAdEntNetMask
the reply will be IP-MIB::ipAdEntNetMask.172.16.38.42 IPV4 255.255.0.0
(So: first index is 172.16.38.42 in that case!)
you iterate and ask next value after IP-MIB::ipAdEntNetMask.172.16.38.42
the reply will be IP-MIB::ipAdEntNetMask.172.16.11.43 IPV4 255.255.0.0
etc.. until there is no other value, or the value is not on the same tree
The service snmp-get-bulk will enable you to query N values directly in this way.
Have a look at Net-Snmp's snmptable that does good job with tables : http://net-snmp.sourceforge.net/wiki/index.php/TUT:snmptable

Resources