I'm trying to dissect a NetSessEnum request over SMB2 (srvsvc opnum 12)
According to Wireshark, a field called Referent_ID seems to have a value of 0x00020000. I can't find proper documentation regarding this field. I'd like to know, if only 0x00020000 is a valid value for this operation or not. Will appreciate pointer to proper documentation on this.
This field is a serialization mark and it may have any value. For instance in our rpc implementation we are using running numbers. This field means a reference and the referenced value comes later according to the serialization rules. The value is meaningless.
Related
As for property names 'isPackageOmited' and 'packageIsOmitted', which should I choose?
Could some native speaker help me?
TLDR: don't put "is" into the middle of the name. It's hard to see quickly. Use isPackageOmitted.
The standard is to always prefix accessors, mutators and predicates with get, set and is.
So you would have methods like getPackage(), setPackage(), and isPackageOmitted().
Even though PackageIsOmitted reads closer to normal English, it is a really good idea to follow the convention of prefixing. It makes it incredibly easy to instantly know that this is a method that retrieves the boolean value.
Compare anIncrediblyLongAnacondaIsAbleToEatSheep with isAnIncrediblyLongAnacondaAbleToEatSheep. The second one instantly tells you that this is a boolean value, while in the first example you have to carefully look through the whole name to figure it out.
Now, if this is just the property, it would probably be best to drop the "is" altogether. Does it really provide any new information? I'd say, generally, it would be best to have a property called packageOmitted and a method isPackageOmitted() to retrieve the property value.
packageIsOmitted is better since "Package is omitted." is an assertion which is either True xor False, whereas "Is Package omitted?" is a question whose answer is either Yes xor No.
This doesn't seem right. Why can't a structure have more than one property per type?
The IDE error message is valid.
Due to the design of Bixby platform (modeling and action planing requires unique concept type), a structure can have at most 1 concept of each type. (The concept could be max(Many) for an array)
One general rule is to name each of your concept and not directly use any core base type. It might seems unnecessary at the beginning, but soon it will start making sense and making things easier for complex capsules.
To fix above error, create a Text type BixbyUserId, and replace with:
property (bixbyuserid) {
type (BixbyUserId)
min (Optional) max (One)
}
The image explain the problem (it isn't absurd??!)
First of all, the -retainCount method returns an unsigned integer, so it, by definition, cannot be negative. You are printing it in the wrong form, because you wrongly assumed it was a signed integer. It is actually NSUIntegerMax.
Second, -retainCount is not useful in general. Even the documentation says:
Do not use this method. (required)
...
This method is of no value in debugging memory management issues.
Because any number of framework objects may have retained an object in
order to hold references to it, while at the same time autorelease
pools may be holding any number of deferred releases on an object, it
is very unlikely that you can get useful information from this method.
Third, classes can override -retainCount and return something custom. This is usually done in classes with custom memory management characteristics, which cannot be described well with a retain count. This is the case here because string objects from string literals are statically allocated, and exist for the whole lifetime of the program. They are not memory-managed. Therefore, they return a bogus retain count of NSUIntegerMax.
There's no doubt that a length-value representation of data is useful, but what advantages are there to type-length-value over it?
Of course, using LV requires the representation to be predefined or structured, but that's hardly ever a problem. Actually, I can't think of a good enough case where it wouldn't be defined enough that TLV would be required.
In my case, this is about data interchange/protocols. In every situation, the representation must be known to both parties to be processed, which eliminates the need for type explicitly inserted in the data. Any thoughts on when the type would be useful or necessary?
Edit
I should mention that a generic parser/processor would certainly benefit from the type information, but that's not my case.
The only decent reason I could come up with is for a generic processor of the data, mainly for debugging or direct user presentation. Having the type embedded within the data would allow the processor to handle the data correctly without having to predefine all possible structures.
The below point was mentioned in the wikipedia.
New message elements which are received at an older node can be safely skipped and the rest of the message can be parsed. This is similar to the way that unknown XML tags can be safely skipped;
Example:
Imagine a message to make a telephone call. In a first version of a system this might use two message elements, a "command" and a "phoneNumberToCall":
command_c/4/makeCall_c/phoneNumberToCall_c/8/"722-4246"
Here command_c, makeCall_c and phoneNumberToCall_c are integer constants and 4 and 8 are the lengths of the "value" fields, respectively.
Later (in version 2) a new field containing the calling number could be added:
command_c/4/makeCall_c/callingNumber_c/8/"715-9719"/phoneNumberToCall_c/8/"722-4246"
A version 1 system which received a message from a version 2 system would first read the command_c element and then read an element of type callingNumber_c.
The version 1 system does not understand ;callingNumber_c
so the length field is read (i.e. the first 8) and the system skips forward 8 bytes to read
phoneNumberToCall_c which it understands, and message parsing carries on.
Without the type field, the version 1 parser would not know to skip callingNumber_c and instead call the wrong number and maybe throw an error on the rest of the message. So the type field allows for forward compatibility in a way that omiting it does not.
I have a string attribute in a Core Data entity whose Max Length value is 40. I'd like to use this value in code and not have to re-type the value "40." Is this possible?
As #K.Steff says in the comments above, you are better off validating in your code and not setting a max length in your core data model. To add on to that comment, I would also advise you to look at using a custom NSManagedObject subclass for this entity type, and within that subclass overriding the validateValue:forKey:error: or implementing a key-specific validation method for this property.
The value of this approach is that you can do things like "coerce" the validation by truncating strings at validation time. From the NSManagedObject documentation:
This method is responsible for two things: coercing the value into an appropriate
type for the object, and validating it according to the object’s rules.
The default implementation provided by NSManagedObject consults the object’s entity
description to coerce the value and to check for basic errors, such as a null value when
that isn’t allowed and the length of strings when a field width is specified for the
attribute. It then searches for a method of the form validate< Key >:error: and invokes it
if it exists.
You can implement methods of the form validate< Key >:error: to perform validation that is
not possible using the constraints available in the property description. If it finds an
unacceptable value, your validation method should return NO and in error an NSError object
that describes the problem. For more details, see “Model Object Validation”. For
inter-property validation (to check for combinations of values that are invalid), see
validateForUpdate: and related methods.
So you can implement this method to both validate that the string is not too long and, if necessary, truncate it when it is too long.
From NSManagedObject you can access the NSEntityDescription via entity. In there you can grab the array properties and a dictionary propertiesByName, either of which will get you to NSPropertyDescriptions. Each property description has a property, validationPredicates that will return an array of NSPredicates. One of those will be the condition that your string length must be at most 40.
Sadly predicates are a lot of hassle to reverse engineer — and doing so can even be impossible, given that you can create one by supplying a block. Hopefully though you'll just have an NSComparisonPredicate or be able to get to one by tree walking downward from an NSCompoundPredicate or an NSExpression.
From the comparison predicate you'll be able to spot from the left and right expressions that one is string length and the other is a constant value.
So, in summary:
Core Data exposes validation criteria only via the very general means of predicates;
you can usually, but not always, rebuild an expression (in the natural language sense rather than the NSExpression sense) from a predicate; and
if you know specifically you're just looking for a length comparison somewhere then you can simplify that further into a tree walk for comparison predicates that involve the length.
It's definitely not going to be pretty because of the mismatch of the specific and the general but it is possible.