tcp-learner issueshttps://gitlab.science.ru.nl/pfiteraubrostean/tcp-learner/-/issues2018-06-01T20:14:16+02:00https://gitlab.science.ru.nl/pfiteraubrostean/tcp-learner/-/issues/1Fix argparse bugs2018-06-01T20:14:16+02:00Paul Fiterau BrosteanFix argparse bugs*By fiter\.\.\. on October 15, 2014 13:19 (imported from Google Code)*
---
Some config parameters in config.cfg are not matched to the sender. For example, if your config.cfg is:
[tcp]
waitTime = 0.1
Then the sender will...*By fiter\.\.\. on October 15, 2014 13:19 (imported from Google Code)*
---
Some config parameters in config.cfg are not matched to the sender. For example, if your config.cfg is:
[tcp]
waitTime = 0.1
Then the sender will still be instantiated with the default values, as defined in argparser.py .
https://gitlab.science.ru.nl/pfiteraubrostean/tcp-learner/-/issues/2Extend mapper with data2018-06-01T20:14:16+02:00Paul Fiterau BrosteanExtend mapper with data*By fiter\.\.\. on October 15, 2014 13:33 (imported from Google Code)*
---
It would be nice if we could have a data extension to the learning and mapper (Learner/src/ sutInterface/tcp/TCPMapper.java).
And thus allow segments to c...*By fiter\.\.\. on October 15, 2014 13:33 (imported from Google Code)*
---
It would be nice if we could have a data extension to the learning and mapper (Learner/src/ sutInterface/tcp/TCPMapper.java).
And thus allow segments to carry a payload of a given length $d (for example 2). The output abstractions would have to reflect that. For example,
SNCLIENTP1 could become SNCLIENTPD
Right now, SNCLIENTP1 highlight a situation when we send a segment carrying seq nr increasing flags (SYN/FIN) and receive an acknowledgement for that segment. With data, this would have to change.
The pitfalls are that the essential lastClientSeqSent state variable can become out of sync with learning.