Joao Antunes | 29 Jan 15:26 2014
Picon

Re: memory leak in ReportMechanism.messageCounters

Hi Reuven!

It was a lifetime ago that I wrote that code, and I wasn't very mindful of the possible leaks. So it might happen. However, I didn't used the code that much to get any kind of idea if there is a leak.

I can tell you what that class is supposed to do and when the messageCounters should be discarded.

Basicly, MSRP allows for chunks of a Message to be sent over the 'wire', therefore, the chunks can be fragmented and arrive in a different sequence from the one they were sent. E.g. with a message that has 1024 bytes, that MSRP finds fit (I don't remember exactly how he decides/negotiates how big the chunks will be, but that's besides the point anyway) to divide in chunks of 128 bytes = 8 chunks. The job of the Counter is to keep track of the chunks it already receives, so that the receive endpoint can send accurate REPORT messages back to the other endpoint when requested.

I guess the perfect moment to clear those counters is when a session is teared down, and all of the Counters associated with the Messages that belong to that Session (now I'm not sure anymore if Messages must belong to a session, or if the same message id can be used across sessions [more unlikely]). But it seems that the Messages do belong to a Session (not a connection, a session can have multiple connections if i'm not mistaken), according to this fragment from the RFC:

"It is possible that an endpoint will receive a REPORT request on a
   session that is no longer valid.  The endpoint's behavior if this
   happens is a matter of local policy.  The endpoint is not required to
   take any steps to facilitate such late delivery; i.e., it is not
   expected to keep a connection active in case late REPORTs might
   arrive."


It has been a lifetime ago, so I added the MSRP mailing list to this discussion so that they can correct me if I'm wrong. 

If you are willing to change the code so that it behaves like that, we would welcome very much your patch so that it could be added to the codebase.

Another optimization that can be done, is that the counter discards the array of bytes or bits that it uses, and replaces it with a simple boolean when all of the message is received. That ought to save memory untill the Session is teared down.

If you have more questions, please contact us.

Cheers,
João Antunes




On Mon, Jan 27, 2014 at 8:59 AM, Reuven Kadison <rkadison <at> interwise.com> wrote:

Hi,

 

I just got a memory leak and found out that DefaultReportMechanism has a member messageCounters (defined in ReportMechanism) that is never cleared.

Can someone please check this?

 

Regards,

Reuven Kadison.

 





************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************




--
João Antunes
_______________________________________________
Simple mailing list
Simple <at> ietf.org
https://www.ietf.org/mailman/listinfo/simple
RFC Errata System | 27 Dec 18:41 2013

[Errata Verified] RFC5438 (3850)

The following errata report has been verified for RFC5438,
"Instant Message Disposition Notification (IMDN)". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5438&eid=3850

--------------------------------------
Status: Verified
Type: Editorial

Reported by: Niket Kumar <niket.kumar <at> intel.com>
Date Reported: 2013-12-26
Verified by: Richard Barnes (IESG)

Section: 8.3

Original Text
-------------
   The aggregated IMDN is constructed using the multipart/mixed MIME
   type and including as individual payloads all the IMDNS that were
   received as message/imdn+xml.

   Below is an example of aggregated IMDNs.

   From: Bob <im:bob <at> example.com>
   To: Alice <im:alice <at> example.com>
   NS: imdn <urn:ietf:params:imdn>
   imdn.Message-ID: d834jied93rf
   Content-type: multipart/mixed;
                      boundary="imdn-boundary"
   Content-Disposition: notification
   Content-length: ...

   --imdn-boundary
   Content-type: message/imdn+xml

   <?xml version="1.0" encoding="UTF-8"?>
   <imdn xmlns="urn:ietf:params:xml:ns:imdn">
         <message-id>34jk324j</message-id>
         <datetime>2008-04-04T12:16:49-05:00</datetime>
        <recipient-uri>im:bob <at> example.com</recipient-uri>
         <original-recipient-uri
           >im:bob <at> example.com</original-recipient-uri>
         <delivery-notification>
            <status>
               <delivered/>
            </status>
         </delivery-notification>
       </imdn>

   --imdn-boundary
   Content-type: message/imdn+xml

   <?xml version="1.0" encoding="UTF-8"?>
   <imdn xmlns="urn:ietf:params:xml:ns:imdn">
         <message-id>34jk324j</message-id>
         <datetime>2008-04-04T12:16:49-05:00</datetime>
        <recipient-uri>im:bob <at> example.com</recipient-uri>
         <original-recipient-uri
            >im:bob <at> example.com</original-recipient-uri>
         <display-notification>
            <status>
               <displayed/>
            </status>
         </display-notification>
       </imdn>

   --imdn-boundary

Corrected Text
--------------
   The aggregated IMDN is constructed using the multipart/mixed MIME
   type and including as individual payloads all the IMDNS that were
   received as message/imdn+xml.

   Below is an example of aggregated IMDNs.

   From: Bob <im:bob <at> example.com>
   To: Alice <im:alice <at> example.com>
   NS: imdn <urn:ietf:params:imdn>
   imdn.Message-ID: d834jied93rf
   Content-type: multipart/mixed;
                      boundary="imdn-boundary"
   Content-Disposition: notification
   Content-length: ...

   --imdn-boundary
   Content-type: message/imdn+xml

   <?xml version="1.0" encoding="UTF-8"?>
   <imdn xmlns="urn:ietf:params:xml:ns:imdn">
         <message-id>34jk324j</message-id>
         <datetime>2008-04-04T12:16:49-05:00</datetime>
        <recipient-uri>im:bob <at> example.com</recipient-uri>
         <original-recipient-uri
           >im:bob <at> example.com</original-recipient-uri>
         <delivery-notification>
            <status>
               <delivered/>
            </status>
         </delivery-notification>
       </imdn>

   --imdn-boundary
   Content-type: message/imdn+xml

   <?xml version="1.0" encoding="UTF-8"?>
   <imdn xmlns="urn:ietf:params:xml:ns:imdn">
         <message-id>34jk324j</message-id>
         <datetime>2008-04-04T12:16:49-05:00</datetime>
        <recipient-uri>im:bob <at> example.com</recipient-uri>
         <original-recipient-uri
            >im:bob <at> example.com</original-recipient-uri>
         <display-notification>
            <status>
               <displayed/>
            </status>
         </display-notification>
       </imdn>

   --imdn-boundary--

Notes
-----
The last multipart MIME boundary should have a "--" at the end. In the above example it should be
"--imdn-boundary--" instead of "--imdn-boundary"

--------------------------------------
RFC5438 (draft-ietf-simple-imdn-10)
--------------------------------------
Title               : Instant Message Disposition Notification (IMDN)
Publication Date    : February 2009
Author(s)           : E. Burger, H. Khartabil
Category            : PROPOSED STANDARD
Source              : SIP for Instant Messaging and Presence Leveraging Extensions
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG
RFC Errata System | 26 Dec 09:59 2013

[Editorial Errata Reported] RFC5438 (3850)

The following errata report has been submitted for RFC5438,
"Instant Message Disposition Notification (IMDN)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5438&eid=3850

--------------------------------------
Type: Editorial
Reported by: Niket Kumar <niket.kumar <at> intel.com>

Section: 8.3

Original Text
-------------
   The aggregated IMDN is constructed using the multipart/mixed MIME
   type and including as individual payloads all the IMDNS that were
   received as message/imdn+xml.

   Below is an example of aggregated IMDNs.

   From: Bob <im:bob <at> example.com>
   To: Alice <im:alice <at> example.com>
   NS: imdn <urn:ietf:params:imdn>
   imdn.Message-ID: d834jied93rf
   Content-type: multipart/mixed;
                      boundary="imdn-boundary"
   Content-Disposition: notification
   Content-length: ...

   --imdn-boundary
   Content-type: message/imdn+xml

   <?xml version="1.0" encoding="UTF-8"?>
   <imdn xmlns="urn:ietf:params:xml:ns:imdn">
         <message-id>34jk324j</message-id>
         <datetime>2008-04-04T12:16:49-05:00</datetime>
        <recipient-uri>im:bob <at> example.com</recipient-uri>
         <original-recipient-uri
           >im:bob <at> example.com</original-recipient-uri>
         <delivery-notification>
            <status>
               <delivered/>
            </status>
         </delivery-notification>
       </imdn>

   --imdn-boundary
   Content-type: message/imdn+xml

   <?xml version="1.0" encoding="UTF-8"?>
   <imdn xmlns="urn:ietf:params:xml:ns:imdn">
         <message-id>34jk324j</message-id>
         <datetime>2008-04-04T12:16:49-05:00</datetime>
        <recipient-uri>im:bob <at> example.com</recipient-uri>
         <original-recipient-uri
            >im:bob <at> example.com</original-recipient-uri>
         <display-notification>
            <status>
               <displayed/>
            </status>
         </display-notification>
       </imdn>

   --imdn-boundary

Corrected Text
--------------
   The aggregated IMDN is constructed using the multipart/mixed MIME
   type and including as individual payloads all the IMDNS that were
   received as message/imdn+xml.

   Below is an example of aggregated IMDNs.

   From: Bob <im:bob <at> example.com>
   To: Alice <im:alice <at> example.com>
   NS: imdn <urn:ietf:params:imdn>
   imdn.Message-ID: d834jied93rf
   Content-type: multipart/mixed;
                      boundary="imdn-boundary"
   Content-Disposition: notification
   Content-length: ...

   --imdn-boundary
   Content-type: message/imdn+xml

   <?xml version="1.0" encoding="UTF-8"?>
   <imdn xmlns="urn:ietf:params:xml:ns:imdn">
         <message-id>34jk324j</message-id>
         <datetime>2008-04-04T12:16:49-05:00</datetime>
        <recipient-uri>im:bob <at> example.com</recipient-uri>
         <original-recipient-uri
           >im:bob <at> example.com</original-recipient-uri>
         <delivery-notification>
            <status>
               <delivered/>
            </status>
         </delivery-notification>
       </imdn>

   --imdn-boundary
   Content-type: message/imdn+xml

   <?xml version="1.0" encoding="UTF-8"?>
   <imdn xmlns="urn:ietf:params:xml:ns:imdn">
         <message-id>34jk324j</message-id>
         <datetime>2008-04-04T12:16:49-05:00</datetime>
        <recipient-uri>im:bob <at> example.com</recipient-uri>
         <original-recipient-uri
            >im:bob <at> example.com</original-recipient-uri>
         <display-notification>
            <status>
               <displayed/>
            </status>
         </display-notification>
       </imdn>

   --imdn-boundary--

Notes
-----
The last multipart MIME boundary should have a "--" at the end. In the above example it should be
"--imdn-boundary--" instead of "--imdn-boundary"

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5438 (draft-ietf-simple-imdn-10)
--------------------------------------
Title               : Instant Message Disposition Notification (IMDN)
Publication Date    : February 2009
Author(s)           : E. Burger, H. Khartabil
Category            : PROPOSED STANDARD
Source              : SIP for Instant Messaging and Presence Leveraging Extensions
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG
Peter Saint-Andre | 19 Jun 19:10 2013

Fwd: [Stox] STOX WG officially approved - charter and work plan

FYI. Please join the stox <at> ietf.org list to participate:

https://www.ietf.org/mailman/listinfo/stox

Peter

-------- Original Message --------
Subject: [Stox] STOX WG officially approved - charter and work plan
Date: Wed, 19 Jun 2013 09:57:28 +0000
From: <Markus.Isomaki <at> nokia.com>
To: <stox <at> ietf.org>
CC: yana <at> jitsi.org

Hi all,

The SIP-to-XMPP (STOX) WG has now been officially approved by the IESG.
Our charter can be found at
<http://datatracker.ietf.org/wg/stox/charter/>. Myself
(markus.isomaki <at> nokia.com) and Yana Stamcheva (yana <at> jitsi.org) will act
as co-chairs.

The plan outlined in the charter is that this will be a focused and
relatively straight-forward effort that we aim to finish in just a few
months. The charter has these milestones:

Jun 2013  Accept starting-point mapping specifications as WG items
Aug 2013  Start Working Group Last Call on mapping specifications
Oct 2013  Submit mapping specifications to the IESG

Yana and I have additionally outlined a bit more detailed plan:

- June: One week consensus call on adopting the current drafts as WG items.
- Latest by July 8: Submit current drafts as -00 WG drafts.
- July: Ask people to comment and raise open issues about the drafts,
ask co-authors to prepare presentations about open issues for IETF 87.
Start recruiting reviewers and if needed, co-authors.
- IETF 87: Meet  for 1 hour. Discuss open issues. Agree on the deadline
for reviews and WG last call on the documents. Decide if all documents
can proceed in the same timeline, or whether some phasing will be needed.
- By end of August: Start the official WG last call.
- September - October: Process last call comments and finalize the
documents for the IESG review.
- IETF 88: Meet if there is interest and energy to discuss about
rechartering, i.e. adding new WG items.

Let us know if you have any feedback to this.

I will next send a few mails to the list about specific topics such as
our first milestone, i.e. the acceptance of the current drafts as WG items.

Markus

_______________________________________________
stox mailing list
stox <at> ietf.org
https://www.ietf.org/mailman/listinfo/stox
hammondjohnson | 27 Apr 20:00 2013

Biggest Fake Conference in Computer Science

We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.

We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware

Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without 
any reviews) and we were invited to submit the final paper and a 
payment of $500+ fee to present the paper. We decided to use the 
fee for better purposes than making Prof. Hamid Arabnia (Chairman 
of WORLDCOMP) rich. After that, we received few reminders from 
WORLDCOMP to pay the fee but we never responded. 

We MUST say that you should look at the above website if you have any thoughts 
to submit a paper to WORLDCOMP.  DBLP and other indexing agencies have stopped 
indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See 
http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the 
conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of
http://sites.google.com/site/dumpconf for comments from well-known researchers 
about WORLDCOMP. 

The status of your WORLDCOMP papers can be changed from scientific
to other (i.e., junk or non-technical) at any time. Better not to have a paper than 
having it in WORLDCOMP and spoil the resume and peace of mind forever!

Our study revealed that WORLDCOMP is a money making business, 
using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing 
out a small chunk of that money (around 20 dollars per paper published 
in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) 
who publicizes WORLDCOMP and also defends it at various forums, using 
fake/anonymous names. The puppet uses fake names and defames other conferences
to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to 
threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). 
That is, the puppet does all his best to get a maximum number of papers published 
at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. 

Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has 
refused to provide the venue for WORLDCOMP’13 because of the fears of their image 
being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 
is taking place at a different resort. WORLDCOMP will not be held after 2013. 

The draft paper submission deadline is over but still there are no committee 
members, no reviewers, and there is no conference Chairman. The only contact 
details available on WORLDCOMP’s website is just an email address! 

Let us make a direct request to Prof. Hamid arabnia: publish all reviews for 
all the papers (after blocking identifiable details) since 2000 conference. Reveal 
the names and affiliations of all the reviewers (for each year) and how many 
papers each reviewer had reviewed on average. We also request him to look at 
the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 

Sorry for posting to multiple lists. Spreading the word is the only way to stop 
this bogus conference. Please forward this message to other mailing lists and people. 

We are shocked with Prof. Hamid Arabnia and his puppet’s activities 
http://worldcomp-fake-bogus.blogspot.com   Search Google using the 
keyword worldcomp fake for additional links.

_______________________________________________
Simple mailing list
Simple <at> ietf.org
https://www.ietf.org/mailman/listinfo/simple
rfc-editor | 22 Apr 21:23 2013

RFC 6914 on SIMPLE Made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence Using the Session Initiation Protocol (SIP)

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6914

        Title:      SIMPLE Made Simple: An Overview 
                    of the IETF Specifications for Instant 
                    Messaging and Presence Using the Session 
                    Initiation Protocol (SIP) 
        Author:     J. Rosenberg
        Status:     Informational
        Stream:     IETF
        Date:       April 2013
        Mailbox:    jdrosen <at> jdrosen.net
        Pages:      15
        Characters: 35472
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-simple-simple-09.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6914.txt

The IETF has produced many specifications related to Presence and
Instant Messaging with the Session Initiation Protocol (SIP).
Collectively, these specifications are known as SIP for Instant
Messaging and Presence Leveraging Extensions (SIMPLE).  This document
serves as a guide to the SIMPLE suite of specifications.  It
categorizes the specifications, explains what each is for, and how
they relate to each other.

This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working
Group of the IETF.

INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor <at> rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

RFC Errata System | 17 Apr 22:08 2013

[Technical Errata Reported] RFC4480 (3596)

The following errata report has been submitted for RFC4480,
"RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4480&eid=3596

--------------------------------------
Type: Technical
Reported by: Ben Campbell <ben <at> nostrum.com>

Section: 5.1

Original Text
-------------
[There are 8 occurrences of the following element in the schema in section 5.1]   

      <xs:attributeGroup ref="fromUntil"/>

Corrected Text
--------------
[Each occurrence should be replaced with the following]

     <xs:attributeGroup ref="dm:fromUntil"/>

Notes
-----
fromUntil is imported from the presence data model namespace
"urn:ietf:params:xml:ns:pidf:data-model". This schema imports that namespace with a prefix of "dm".
(see beginning of section 5.1)  The prefix was left off of the "fromUntil" entries.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4480 (draft-ietf-simple-rpid-10)
--------------------------------------
Title               : RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)
Publication Date    : July 2006
Author(s)           : H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg
Category            : PROPOSED STANDARD
Source              : SIP for Instant Messaging and Presence Leveraging Extensions
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG
Robert Sparks | 22 Mar 17:11 2013

Errata and update to RFC5261

All -

If you haven't noticed, there's been a discussion on apps-discuss around 
updating RFC5261, and some errata posted along with that discussion.

Erik (copied) has a draft in the works that would address the errata.

See <http://tools.ietf.org/html/draft-wilde-xml-patch-04#appendix-A> and
<http://www.rfc-editor.org/errata_search.php?rfc=5261&rec_status=2&presentation=records>

I recommend putting the errata into Hold for Document Update and work 
out the details as part of the development of that update.

If you are interested, please engage in the discussion on Erik's draft 
on apps-discuss (or where the ADs guide you).

RjS
Andrew Allen | 11 Mar 15:25 2013

test please ignore

 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
_______________________________________________
Simple mailing list
Simple <at> ietf.org
https://www.ietf.org/mailman/listinfo/simple
IESG Secretary | 26 Feb 21:57 2013
Picon

WG Action: Conclusion of SIP for Instant Messaging and Presence Leveraging Extensions (simple)

The SIP for Instant Messaging and Presence Leveraging Extensions (simple) in the 
Real-time Applications and Infrastructure Area has concluded. The IESG contact 
persons are Gonzalo Camarillo and Robert Sparks.

The mailing list will remain open.
Robert Sparks | 26 Feb 17:50 2013

Closing the SIMPLE WG

Folks -

With the last of SIMPLE's documents going into the RFC Editor queue,
I'm closing the group. It's been a long road since we demonstrated
running code in Pittsburg at IETF 48's IMPP meeting in the summer
of 2000. It's been great to be part of helping evolve those early ideas.

I'm sure there will be new things to do related to SIMPLE in the future, 
and
anticipate that we'll form new, focused working groups to work through them.
DISPATCH will help us find the right structure to get any new work done.

Thanks to everyone for the effort you've put into this working group over
the years. I'm proud to have been a part of it.

RjS

Gmane