search

xlab / at

AT is a framework written in Go for communication with AT-compatible devices like Huawei modems via serial port.
MIT License
120 stars 53 forks source link

Refactoring #27

Closed dmke closed 2 years ago

dmke commented 2 years ago

I've refactored some bits:

Split code

I've split the sms/sms.go file in multiple units, as 1000-lines files start to get unwieldy.

For the same reason, I've split the switch statements in (*sms.Message).PDU() and (*sms.Message).ReadFrom() in separate methods.

Add a resolver for TP-ST values

I've imported the names for TP-ST values from 3GPP TS 23.040 v16.0.0, section 9.2.3.15 (PDF). This allows to easier act on SMS-STATUS-REPORT PDUs:

var m sms.Message
_, _ = m.ReadFrom(utils.MustBytes(statusReportPDU))

switch m.Status.Category() {
case sms.StatusCategories.Complete:
    // Short message transaction completed
case sms.StatusCategories.TemporaryError:
    // Temporary error, SC still trying to transfer SM
case sms.StatusCategories.PermanentError:
    // Permanent error, SC is not making any more transfer attempts
case sms.StatusCategories.FinalError:
    // Temporary error, SC is not making any more transfer attempts
case sms.StatusCategories.Unknown:
    // Status code is either reserved or SC-specific
}

I'm not sure about the Status field names: TS 23.040 reuses some names for different bytes (which either carry the information that the SC will or will not retry delivery, or whether the status is temporary or permanent). Hence the names of sms.StatusCodes are prefixed with on of:

Add type-of-address and numbering-plan-indentification for PhoneNumber

I've imported values for type-of-address and numbering-plan-identification bits from 3GPP TS 23.040, section 9.1.2.5.

The code does not make much use of it (as it only supports national/international E164 numbers for PDU-encoding and additionally alphanumeric numbers for parsing), but I guess this is the best place to put those constants.

Small fixes related to time zone

In (Timestamp).PDU(), generating the time zone octet accidentally used integer arithmetic to calculate the GMT offset. This causes problems for time zones like +08:15, which resulted in an offset of 8 hours (and not 8.25 hours).

In (*Timestamp).ReadFrom(), the wrong bit was used to identify negative time zones: Negative time zones are actually indicated by bit 3 (the fourth bit, 0x08, 0b0000_1000) set to one, this code previously looked at bit 2 (0x04, 0b0000_0100). This also surfaced an issue with the test fixture for TestSmsDeliverReadFromGsm7_2() where the correct time zone is GMT-03:00 (Moscow time, which matches the TP-UD payload contained in that message).

codecov-commenter commented 2 years ago

Codecov Report

Merging #27 (9462a3e) into master (853be59) will increase coverage by 2.48%. The diff coverage is 60.15%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master      #27      +/-   ##
==========================================
+ Coverage   35.44%   37.93%   +2.48%     
==========================================
  Files           8       17       +9     
  Lines        1560     1558       -2     
==========================================
+ Hits          553      591      +38     
+ Misses        915      884      -31     
+ Partials       92       83       -9
Impacted Files Coverage Δ
sms/user_data_header.go 0.00% <0.00%> (ø)
sms/ussd.go 0.00% <0.00%> (ø)
sms/validity_period.go 33.33% <33.33%> (ø)
sms/sms_status_report.go 35.15% <35.15%> (ø)
sms/sms_submit.go 46.87% <46.87%> (ø)
sms/sms_deliver.go 51.16% <51.16%> (ø)
sms/phone_number.go 74.41% <74.41%> (ø)
sms/sms.go 71.16% <79.29%> (+18.11%) :arrow_up:
pdu/7bit.go 88.80% <80.00%> (-1.96%) :arrow_down:
sms/status.go 100.00% <100.00%> (ø)
... and 2 more

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 853be59...9462a3e. Read the comment docs.

dmke commented 2 years ago

This is now ready for review. I've updated the cover letter.

xlab commented 2 years ago

where the correct time zone is GMT-03:00 (Moscow time, which matches the TP-UD payload contained in that message).

It's GMT+03 by the way, but I believe that the wrong bit could be used to detect that. I didn't have a chance to test with other zones with real data.

Thanks!