[sip-comm-dev] [gsoc] Map an IM protocol on to a P2P architecture


#1

Hi Emil, Vincent and other developers.

I'm Aimar Gonzalez, the student at charge of the JXTA support for SipComm.
For the one that are not familiarized with JXTA you can take it as a
transport layer that allows you to deploy p2p infrastructure over any real
network topology. JXTA allows us to work with a p2p network were peers and
services publish and communicate seamlessly.

As JXTA can be taken as a transport layer I've to found a IM protocol to put
over it. I need a protocol that can behave well in a p2p abstraction.

I've been studding some of them. The problem is that most of them
havefeatures that require some type of persistent server. Most common
example is
the user settings, identity register, user roster management, etc.

This collides with the p2p paradigm because it forces us to centralize
services over a p2p network, so we loose most of JXTA features. Also taking
into account that JXTA provides a DHT managed p2p network which is loosely
consistent, one cannot rely on centralized permanent services.

So my first approach is to delete this kind of services of the IM protocol.
The result is:

    - allows to join the service without previous service.
    - free election of nickname (if it is not already in use)
    - private chats (one to one)
    - public chat rooms (but no persistent)
    - private chat rooms (also not persistent)
    - loosely-consistent users location (you see the presence of people in
the same channels as you or you can inquiry presence for known nickname, but
a presence roster is not maintained).

You may already noticed that this approaches much more a IRC paradigm than a
MSN/XMPP paradigm. In fact, IRC protocol can be easly adapted to a
JXTAtransport. Anyway I'm not talking about porting the
IRC spec to JXTA but to implement something similar.

What I would like to know is if this paradigm without friends roster fits
within what SipComm wants. I'm not saying this is the only approach that can
be taken but it is the one that fits more naturally given that JXTA doesn't
have any IM infrastructure.

I would really know your opinion and suggestions about this. Anyway I've
been told of a course on my university that learn JXTA and implement
some IMstuff on it. I forward getting some documentation from there to
get ideas.

Don't hesitate to reply, and comment the proposal.

Thank you,

Aimar.


#2

Hello Aimar,

Nice to see you on the list!

In your previous mails on the gsoc mailing list you mentioned two existing IMP clients using JXTA - J.I.M. and myjxta(2). How do they handle contact lists? Do they save them locally?

Isn't there a way of storing a roster in the overlay? Doest JXTA offer a data storage service that you could use to do this?

If no then we can also store our lists locally. That's what we do anyway since the meta contact list would store them no matter whether they are kept on a server or not so that's really not that much of an issue.

What I would like to know is if this paradigm without friends roster fits within what SipComm wants.

It certainly is not a problem in itself. One thing that is very important for us however is keeping compatibility with existing software. (such as J.J.M. and myjxta(2) ). I'd personally say that it would be a good idea to simply choose one of the two clients and implement support for the protocol it uses in SIP Communicator.

WDYT?

Emil

MeL wrote:

···

Hi Emil, Vincent and other developers.

I'm Aimar Gonzalez, the student at charge of the JXTA support for SipComm. For the one that are not familiarized with JXTA you can take it as a transport layer that allows you to deploy p2p infrastructure over any real network topology. JXTA allows us to work with a p2p network were peers and services publish and communicate seamlessly.

As JXTA can be taken as a transport layer I've to found a IM protocol to put over it. I need a protocol that can behave well in a p2p abstraction.

I've been studding some of them. The problem is that most of them have features that require some type of persistent server. Most common example is the user settings, identity register, user roster management, etc.

This collides with the p2p paradigm because it forces us to centralize services over a p2p network, so we loose most of JXTA features. Also taking into account that JXTA provides a DHT managed p2p network which is loosely consistent, one cannot rely on centralized permanent services.

So my first approach is to delete this kind of services of the IM protocol. The result is:

    - allows to join the service without previous service.
    - free election of nickname (if it is not already in use)
    - private chats (one to one)
    - public chat rooms (but no persistent)
    - private chat rooms (also not persistent)
    - loosely-consistent users location (you see the presence of people in the same channels as you or you can inquiry presence for known nickname, but a presence roster is not maintained).

You may already noticed that this approaches much more a IRC paradigm than a MSN/XMPP paradigm. In fact, IRC protocol can be easly adapted to a JXTA transport. Anyway I'm not talking about porting the IRC spec to JXTA but to implement something similar.

What I would like to know is if this paradigm without friends roster fits within what SipComm wants. I'm not saying this is the only approach that can be taken but it is the one that fits more naturally given that JXTA doesn't have any IM infrastructure.

I would really know your opinion and suggestions about this. Anyway I've been told of a course on my university that learn JXTA and implement some IM stuff on it. I forward getting some documentation from there to get ideas.

Don't hesitate to reply, and comment the proposal.

Thank you,

Aimar.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi Vincent, Emil and devs, I'm back,

I was seeking about your queries and this is what i've found.

JXTA IM Communication:
  - One to One

JXTA IM Roster:
  - User built roster (allows to add friends manually)
  - Stored locally (metacontact object serialized to a file)

JXTA IM Presence
  - Persistent presence only on the buddy list (ping?pong! approach)

JXTA IM Peer Discovery
  - It makes a general peer discovery on the start, and save the reached
advertisements in local cache. Later searches are resolved locally.

MyJXTA Communication:
  - One to one
  - One to many (group chats)

MyJXTA Roster:
  - Automatically built roster (roster = list of ChatGroup members)
  - It's not stored.

MyJXTA Presence
  -Presence provided from the Roster plugin. But with a developer note: "it
was not the intention of the author to implement a very clever
implementation of the typical p2p presence problem". This is not a
Persistent Presence implementation. It only checks the group members state
once on the logon stage and once again when login out. (uses a ping ping
approach too)

About to keep the compatibility with one of them. Nowadays JXTA IM is a dead
project: there are no activity in the mailing lists, and asac (the main
developer) tells me that the project is discontinued. Then, JXTA IM is a bad
candidate.

For the other side MyJXTA look so better. But the presence rusty solution is
an important issue. It would be the better candidate comparing both. But the
compatibility with MyJXTA may be drives me to a badly implementation. In my
opinion the Presence & Roaster solutions that I can implement may be easily
better than MyJXTA ones.

WDYT ?

Don't hesitate to reply and give your opinion.

Best regards,

Aimar.

···

On 5/18/07, Emil Ivov <emcho@emcho.com> wrote:

Hello Aimar,

Nice to see you on the list!

In your previous mails on the gsoc mailing list you mentioned two
existing IMP clients using JXTA - J.I.M. and myjxta(2). How do they
handle contact lists? Do they save them locally?

Isn't there a way of storing a roster in the overlay? Doest JXTA offer a
data storage service that you could use to do this?

If no then we can also store our lists locally. That's what we do anyway
since the meta contact list would store them no matter whether they are
kept on a server or not so that's really not that much of an issue.

> What I would like to know is if this paradigm without friends roster
> fits within what SipComm wants.

It certainly is not a problem in itself. One thing that is very
important for us however is keeping compatibility with existing
software. (such as J.J.M. and myjxta(2) ). I'd personally say that it
would be a good idea to simply choose one of the two clients and
implement support for the protocol it uses in SIP Communicator.

WDYT?

Emil

MeL wrote:
>
> Hi Emil, Vincent and other developers.
>
> I'm Aimar Gonzalez, the student at charge of the JXTA support for
> SipComm. For the one that are not familiarized with JXTA you can take it
> as a transport layer that allows you to deploy p2p infrastructure over
> any real network topology. JXTA allows us to work with a p2p network
> were peers and services publish and communicate seamlessly.
>
> As JXTA can be taken as a transport layer I've to found a IM protocol to
> put over it. I need a protocol that can behave well in a p2p
abstraction.
>
> I've been studding some of them. The problem is that most of them have
> features that require some type of persistent server. Most common
> example is the user settings, identity register, user roster management,
> etc.
>
> This collides with the p2p paradigm because it forces us to centralize
> services over a p2p network, so we loose most of JXTA features. Also
> taking into account that JXTA provides a DHT managed p2p network which
> is loosely consistent, one cannot rely on centralized permanent
services.

> So my first approach is to delete this kind of services of the IM
> protocol. The result is:
>
> - allows to join the service without previous service.
> - free election of nickname (if it is not already in use)
> - private chats (one to one)
> - public chat rooms (but no persistent)
> - private chat rooms (also not persistent)
> - loosely-consistent users location (you see the presence of people
> in the same channels as you or you can inquiry presence for known
> nickname, but a presence roster is not maintained).
>
> You may already noticed that this approaches much more a IRC paradigm
> than a MSN/XMPP paradigm. In fact, IRC protocol can be easly adapted to
> a JXTA transport. Anyway I'm not talking about porting the IRC spec to
> JXTA but to implement something similar.
>
> What I would like to know is if this paradigm without friends roster
> fits within what SipComm wants. I'm not saying this is the only approach
> that can be taken but it is the one that fits more naturally given that
> JXTA doesn't have any IM infrastructure.

> I would really know your opinion and suggestions about this. Anyway I've
> been told of a course on my university that learn JXTA and implement
> some IM stuff on it. I forward getting some documentation from there to
> get ideas.
>
> Don't hesitate to reply, and comment the proposal.
>
> Thank you,
>
> Aimar.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hello Aimar,

Personally, I was insisting on compatibility partially because it would be simply cool to have it and be able to communicate with existing clients, but also because we were sure to get you going in a direction that is sure to lead to something working.

If,you are sure that you'd have the time to both devise an IMP protocol and implement it, given that mid-term GSoC evals are not that far (July 9th) you could certainly head that way.

You may also want to have a look at SIMPLE. Though not originally designed for P2P, SIMPLE works quite well for point-to-point presence. However, I really don't know JXTA that well so it's all your call.

Let us know once you've made up your mind.

Cheers
Emil

MeL wrote:

···

Hi Vincent, Emil and devs, I'm back,

I was seeking about your queries and this is what i've found.

JXTA IM Communication:
  - One to One

JXTA IM Roster:
  - User built roster (allows to add friends manually)
  - Stored locally (metacontact object serialized to a file)
JXTA IM Presence
  - Persistent presence only on the buddy list (ping?pong! approach)

JXTA IM Peer Discovery
  - It makes a general peer discovery on the start, and save the reached advertisements in local cache. Later searches are resolved locally.

MyJXTA Communication:
  - One to one
  - One to many (group chats)

MyJXTA Roster:
  - Automatically built roster (roster = list of ChatGroup members)
  - It's not stored.

MyJXTA Presence
  -Presence provided from the Roster plugin. But with a developer note: "it was not the intention of the author to implement a very clever implementation of the typical p2p presence problem". This is not a Persistent Presence implementation. It only checks the group members state once on the logon stage and once again when login out. (uses a ping ping approach too)

About to keep the compatibility with one of them. Nowadays JXTA IM is a dead project: there are no activity in the mailing lists, and asac (the main developer) tells me that the project is discontinued. Then, JXTA IM is a bad candidate.

For the other side MyJXTA look so better. But the presence rusty solution is an important issue. It would be the better candidate comparing both. But the compatibility with MyJXTA may be drives me to a badly implementation. In my opinion the Presence & Roaster solutions that I can implement may be easily better than MyJXTA ones.

WDYT ?

Don't hesitate to reply and give your opinion.

Best regards,

Aimar.

On 5/18/07, *Emil Ivov* < emcho@emcho.com <mailto:emcho@emcho.com>> wrote:

    Hello Aimar,

    Nice to see you on the list!

    In your previous mails on the gsoc mailing list you mentioned two
    existing IMP clients using JXTA - J.I.M. and myjxta(2). How do they
    handle contact lists? Do they save them locally?

    Isn't there a way of storing a roster in the overlay? Doest JXTA
    offer a
    data storage service that you could use to do this?

    If no then we can also store our lists locally. That's what we do anyway
    since the meta contact list would store them no matter whether they are
    kept on a server or not so that's really not that much of an issue.

     > What I would like to know is if this paradigm without friends roster
     > fits within what SipComm wants.

    It certainly is not a problem in itself. One thing that is very
    important for us however is keeping compatibility with existing
    software. (such as J.J.M. and myjxta(2) ). I'd personally say that it
    would be a good idea to simply choose one of the two clients and
    implement support for the protocol it uses in SIP Communicator.

    WDYT?

    Emil

    MeL wrote:
     >
     > Hi Emil, Vincent and other developers.
     >
     > I'm Aimar Gonzalez, the student at charge of the JXTA support for
     > SipComm. For the one that are not familiarized with JXTA you can
    take it
     > as a transport layer that allows you to deploy p2p infrastructure
    over
     > any real network topology. JXTA allows us to work with a p2p network
     > were peers and services publish and communicate seamlessly.
     >
     > As JXTA can be taken as a transport layer I've to found a IM
    protocol to
     > put over it. I need a protocol that can behave well in a p2p
    abstraction.
     >
     > I've been studding some of them. The problem is that most of them
    have
     > features that require some type of persistent server. Most common
     > example is the user settings, identity register, user roster
    management,
     > etc.
     >
     > This collides with the p2p paradigm because it forces us to
    centralize
     > services over a p2p network, so we loose most of JXTA features. Also
     > taking into account that JXTA provides a DHT managed p2p network
    which
     > is loosely consistent, one cannot rely on centralized permanent
    services.

     > So my first approach is to delete this kind of services of the IM
     > protocol. The result is:
     >
     > - allows to join the service without previous service.
     > - free election of nickname (if it is not already in use)
     > - private chats (one to one)
     > - public chat rooms (but no persistent)
     > - private chat rooms (also not persistent)
     > - loosely-consistent users location (you see the presence of
    people
     > in the same channels as you or you can inquiry presence for known
     > nickname, but a presence roster is not maintained).
     >
     > You may already noticed that this approaches much more a IRC paradigm
     > than a MSN/XMPP paradigm. In fact, IRC protocol can be easly
    adapted to
     > a JXTA transport. Anyway I'm not talking about porting the IRC
    spec to
     > JXTA but to implement something similar.
     >
     > What I would like to know is if this paradigm without friends roster
     > fits within what SipComm wants. I'm not saying this is the only
    approach
     > that can be taken but it is the one that fits more naturally
    given that
     > JXTA doesn't have any IM infrastructure.

     > I would really know your opinion and suggestions about this.
    Anyway I've
     > been told of a course on my university that learn JXTA and implement
     > some IM stuff on it. I forward getting some documentation from
    there to
     > get ideas.
     >
     > Don't hesitate to reply, and comment the proposal.
     >
     > Thank you,
     >
     > Aimar.

    ---------------------------------------------------------------------
    To unsubscribe, e-mail:
    dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    For additional commands, e-mail:
    dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net