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@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@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)