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
Index: mmsc/mmsproxy.c
===================================================================
RCS file: /cvsroot/mbuni/mbuni/mmsc/mmsproxy.c,v
retrieving revision 1.33
diff -u -r1.33 mmsproxy.c
--- mmsc/mmsproxy.c 17 Feb 2006 11:48:33 -0000 1.33
+++ mmsc/mmsproxy.c 21 Feb 2006 15:05:14 -0000
@@ -139,8 +139,15 @@
octstr_strip_nonalphanums(profile_url);
h.prof = mms_get_ua_profile(octstr_get_cstr(profile_url));
octstr_destroy(profile_url);
- } else
- h.prof = mms_make_ua_profile(h.headers);
+ }
+
+ /* In case profile_url is missing or we haven't cached it yet,
+ * use a fall back strategy and construct profile from HTTP
headers.
+ * XXX: Do we need to make mms_get_ua_profile()
+ * construct profile even if it's not cached?
+ */
+ if (!h.prof)
+ h.prof = mms_make_ua_profile(h.headers);
/* Get the sender address. */
h.base_client_addr = mms_find_sender_msisdn(h.url,
_______________________________________________
Devel mailing list
Devel@mbuni.org
http://mbuni.org/mailman/listinfo/devel_mbuni.org
