Hi, Paul, thanks for the comments but IMHO this is not the behaviour most users want. Imagine yourself working in some customer care and every second user calls asking what does the message "Mobile MMS Settings not found" blaming him or her means. Is it really worth 1-2 seconds of blocking the uaprof fetching proxy?
What is more, mbuni already has a fall-back capabilities negotiation strategy based on HTTP headers implemented, so why not to use it in case we don't have uaprof cached? Another solutions, such as using a central profiles repository databases like WURFL (http://wurfl.sourceforge.net/), which recently introduced C++ API, also exist. Basically I could try to implement a patch for this problem, before this I would like to hear opinions about the capabilities negotiation strategy. Thanks. On 2/13/06, Paul Bagyenda <[EMAIL PROTECTED]> wrote: > Dzuigas, > > This behaviour is intentional... I didn't think it wise for the > proxy to block while it tries to retrieve the UA Profile from the > Internet. Best to temporarily fail, so that client retries, by which > time the profile will have been downloaded... > > P. > > On Feb 11, 2006, at 11:01, Dziugas Baltrunas wrote: > > > Hi, > > > > I found out another bug related with uaprof. When starting mbuni with > > empty spool dir and sending an MMS, receiver gets a message with text > > "Mobile MMS Settings not found". For the second time (when then uaprof > > is cached) this issue no longer occurs. Here is what debug log shows: > > > > 2006-02-11 09:54:02 [6327] [7] DEBUG: $$$$$$ fetch message [fail] > > replying with [type=m-retrieve-conf,content_len=125]: > > [...] > > 2006-02-11 09:54:02 [6327] [7] DEBUG: data: 58 2d 4d 6d 73 2d 52 65 > > 74 72 69 65 76 65 2d 53 X-Mms-Retrieve-S > > 2006-02-11 09:54:02 [6327] [7] DEBUG: data: 74 61 74 75 73 3a 20 45 > > 72 72 6f 72 2d 74 72 61 tatus: Error-tra > > 2006-02-11 09:54:02 [6327] [7] DEBUG: data: 6e 73 69 65 6e 74 2d 66 > > 61 69 6c 75 72 65 nsient-failure > > 2006-02-11 09:54:02 [6327] [7] DEBUG: Octet string dump ends. > > > > And it looks like only afterwards profile is being fetched: > > > > 2006-02-11 09:54:02 [6327] [7] DEBUG: Dumping MMS message body (not > > multipart) [0 parts] --> > > 2006-02-11 09:54:02 [6327] [7] DEBUG: HTTP: Destroying HTTPClient area > > 0x8d93f80. > > 2006-02-11 09:54:02 [6327] [7] DEBUG: HTTP: Destroying HTTPClient for > > `192.168.150.2'. > > 2006-02-11 09:54:02 [6327] [7] DEBUG: entered free_clientinfo 1, > > ip=148455712 > > 2006-02-11 09:54:02 [6327] [7] DEBUG: left free_clientinfo > > 2006-02-11 09:54:02 [6327] [7] DEBUG: Thread 7 > > (mmsproxy.c:(gwthread_func_t *)fetchmms_proxy) terminates. > > 2006-02-11 09:54:02 [6327] [6] DEBUG: HTTP: Opening connection to > > `nds1.nds.nokia.com:80' (fd=25). > > 2006-02-11 09:54:02 [6327] [6] DEBUG: Socket connecting > > 2006-02-11 09:54:02 [6327] [5] DEBUG: Get info about connecting socket > > 2006-02-11 09:54:02 [6327] [5] DEBUG: HTTP: Sending request: > > 2006-02-11 09:54:02 [6327] [5] DEBUG: Octet string at 0x8d8fa10: > > 2006-02-11 09:54:02 [6327] [5] DEBUG: len: 93 > > 2006-02-11 09:54:02 [6327] [5] DEBUG: size: 1024 > > 2006-02-11 09:54:02 [6327] [5] DEBUG: immutable: 0 > > 2006-02-11 09:54:02 [6327] [5] DEBUG: data: 47 45 54 20 2f 75 61 70 > > 72 6f 66 2f 4e 36 32 33 GET /uaprof/N623 > > 2006-02-11 09:54:02 [6327] [5] DEBUG: data: 30 72 32 30 30 2e 78 6d > > 6c 20 48 54 54 50 2f 31 0r200.xml HTTP/1 > > 2006-02-11 09:54:02 [6327] [5] DEBUG: data: 2e 31 0d 0a 48 6f 73 74 > > 3a 20 6e 64 73 31 2e 6e .1..Host: nds1.n > > 2006-02-11 09:54:02 [6327] [5] DEBUG: data: 64 73 2e 6e 6f 6b 69 61 > > 2e 63 6f 6d 0d 0a 55 73 ds.nokia.com..Us > > 2006-02-11 09:54:02 [6327] [5] DEBUG: data: 65 72 2d 41 67 65 6e 74 > > 3a 20 4d 62 75 6e 69 2f er-Agent: Mbuni/ > > 2006-02-11 09:54:02 [6327] [5] DEBUG: data: 31 2e 30 2e 30 2d 63 76 > > 73 0d 0a 0d 0a 1.0.0-cvs.... > > 2006-02-11 09:54:02 [6327] [5] DEBUG: Octet string dump ends. > > > > Here is the relevant code in mmsc/mmsproxy.c: > > > > if (settings->content_adaptation) { > > MmsMsg *outmsg = NULL; > > int x = mms_transform_msg(m, h->prof, &outmsg); > > > > if (x == -1) { /* Temporary failure, we need to fetch > > profile. */ > > mr = mms_retrieveconf(NULL, transid, "Error- > > transient-failure", > > "Mobile MMS Settings not found", > > settings->system_user,MS_1_1); > > s = mms_tobinary(mr); > > goto failed; > > > > On 2/10/06, Dziugas Baltrunas <[EMAIL PROTECTED]> wrote: > >> Hi, > >> > >> I noticed that a thread mmlib/mms_uaprof.c:mms_profile_fetcher() is > >> started from three places (call to mms_start_profile_engine): > >> mmsc/mmsrelay.c:main(), mmsc/mmsproxy.c:main() and > >> mmsc/mmssend.c:main(). The last one IMHO should be removed entirely > >> from CVS and for the two former ones there should be either a > >> decision > >> which process (i.e. mmsrelay or mmsproxy) should create the thread or > >> a check if a thread does not yet exist (which I guess is not an easy > >> task since thread is started from separate processes). > >> > >> To clarify the situation, having both mmsrelay and mmsproxy running > >> and sending a TERM to both, tail of debug log shows it: > >> > >> 2006-02-10 18:21:01 [32311] [1] DEBUG: Fetcher shutdown... > >> 2006-02-10 18:21:01 [32311] [1] DEBUG: Thread 1 > >> (mms_uaprof.c:(gwthread_func_t *)mms_profile_fetcher) terminates. > >> 2006-02-10 18:21:03 [32311] [0] DEBUG: Immutable octet strings: 773. > >> 2006-02-10 18:21:05 [32313] [1] DEBUG: Fetcher shutdown... > >> 2006-02-10 18:21:05 [32313] [1] DEBUG: Thread 1 > >> (mms_uaprof.c:(gwthread_func_t *)mms_profile_fetcher) terminates. > >> 2006-02-10 18:21:07 [32313] [0] DEBUG: Immutable octet strings: 776. > >> > >> -- > >> Dziugas > >> > > > > > > -- > > Dziugas > > > > _______________________________________________ > > Devel mailing list > > Devel@mbuni.org > > http://mbuni.org/mailman/listinfo/devel_mbuni.org > > ----------------------------------------------- > Trek the Rwenzori's. Or just see them online - http://www.rwenzori.com/ > > > _______________________________________________ > Devel mailing list > Devel@mbuni.org > http://mbuni.org/mailman/listinfo/devel_mbuni.org > -- Dziugas _______________________________________________ Devel mailing list Devel@mbuni.org http://mbuni.org/mailman/listinfo/devel_mbuni.org
