thanks, updated. On Feb 21, 2006, at 18:07, Dziugas Baltrunas wrote: > Hi, > > ok, the small patch attached tries to use a fallback strategy in case > we're fetching uaprof for the first time. However, I think it would be > still valuable to fetch and parse the uaprof on demand (or at least > make a possibility to enable it in the config). > > On 2/20/06, Paul Bagyenda <[EMAIL PROTECTED]> wrote: >> 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 >> > > > -- > Dziugas > <uaprof.patch> > _______________________________________________ > 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
