Thanks Harald for the detailed writeup and the work to get a large
NextEPC network up and running.
Regarding point 2, I think it might be good to consider starting with
only a programmatic interface (CTRL or some kind of RPC framework
possibly?) integrated directly into the EPC code, and then providing the
end UI to users as a client of the programmatic interface. This would
allow separating out the client UI code from the core EPC components
more easily, and make it more scalable to add additional interfaces as
needed (I.E. a web gui and a telnet cli existing in parallel, with
access to the same underlying functionality).
-Matt J.
On 8/27/19 10:14 AM, Sukchan Lee wrote:
See inline!
On Tue, Aug 27, 2019 at 11:40 PM Harald Welte <laforge(a)gnumonks.org
<mailto:laforge@gnumonks.org>> wrote:
Hi Sukchan,
On Tue, Aug 27, 2019 at 11:20:37PM +0900, Sukchan Lee wrote:
I'm really surprising that nextepc can
support such a large people.
What I'm personally quite happy is that I couldn't see any clear
memory
leaks. Knowing from experience, this is one of the hardest tasks in
development of complex C-language software.
1. ogs_expect()
I think that ogs_expect() is really good starting point to remove
unnecessary ogs_assert().
So, I added my version in ogslib() repository as below.
#define ogs_expect(expr, fallback) \
do { \
if (ogs_likely(expr)) ; \
else { \
ogs_error("%s: Expectation `%s' failed.", OGS_FUNC,
#expr); \
fallback; \
} \
} while (0)
Let me know if the above interface has a problem.
I don't see a problem, other than the code looking - from my point
of view
"ugly". having return statements inside a macro argument is
highly unusual,
AFAICT.
Also, in your version, how would a "print a message but do nothing
else" look like?
I think it would be "ogs_expect(ret == OGS_OK, );" where the empty
second argument
looks completely unlike C code at all...
I understand your motivation and I was also thinking about
something like this
originally, but I decided against it. At least at the moment most
of your
related functions return 'void' anyway, so my
ogs_expect_or_return() worked fine.
I think as soon as you want to do something else but either
nothing or return,
then you need to introduce a proper if-clause with error
handling. That's why
I introduced only those two versions and not a flexible variant.
Ah! Now, I understand your intention. So I did rollback
ogs_expect_or_return().
Thank you for introducing a good interface.
2. VTY/CTRL
I'm happy if nextepc can have such a good VTY/CTL. Indeed, this
is
actually
needed if someone would like to test nextepc on a
large scale.
As indicated, the question is whether I should simply start adding
Osmocom VTY
using libosmocore, or if we should spend some more time looking
for alternatives
or even designing + writing some new, better system and then
introduce this to
nextepc. I'm a bit undecided here at this point. Take the quick
route or the long
path...
Basically, I planned to implement HTTP/JSON for this part(e.g. GET
/ue, POST /logging). And also, I'd like to monitor the status in the
WebUI. However, to do so, we need to create one process to handle it.
IMHO, it will take a long to implement it. I also don't know which one
is better for us.
3. Logging
I agree that IMSI, APN context is needed when logging. So, I think
mme_log()/sgw_log()/... needs to be introduced. And also, I saw
a fix of
the freeDiameter logging. How about merging it
to master
branch. Please
github pull request if you agree.
It's probably even more like a mme_ue_log() or something like
that, because you
may have different objects/structs which provide loggign context.
In Osmocom we have introduced log macros like LOG_MSC_A(),
LOG_MNCC_CALL(), lOG_MSUB()
where the first argument is typically the 'object' providing
context. Those macros then
expand to a call to the generic logging macro/function.
I saw your work! LOG macro with context adds the prefix logging. I
will refer your work when I improve a logging.
--
- Harald Welte <laforge(a)gnumonks.org
<mailto:laforge@gnumonks.org>>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300
175-7 Ch. A6)