I think you make a fair point, and certainly this is not something that at least I thought long and deep about. A fall back would be a nice idea, assuming the client always sends the relevant HTTP headers.
So yes, a patch that we can all discuss would be a good idea. P. On Feb 19, 2006, at 19:41, Dziugas Baltrunas wrote: > 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 ----------------------------------------------- Trek the Rwenzori's. Or just see them online - http:// www.rwenzori.com/gallery.htm _______________________________________________ Devel mailing list Devel@mbuni.org http://mbuni.org/mailman/listinfo/devel_mbuni.org
