cpp-netlib-devel

[cpp-netlib-devel] Some thoughts, XMPP work etc.

[Reetesh M. <ree...@gm...>]

Hi Dean and All,

I have been going through the code development in cpp-netlib for last 6
months. I have been experimenting on XMPP for a while, (
http://tarang.xmpp.googlepages.com/) and have done some crude
implementations (see svn). With time, I am planning to stick to cpp-netlib
codes, for their is no meaning of implementing things in XMPP which are
already in cpp-netlib. That said, now onwards I will like to put my view
points (and also codes in cpp-netlib ;-) ), for it will have direct impact
on XMPP design. I have some points in my mind:-


   1. basic_message<...> class resembles basic_string<...> class. I think
   this class very well fits in the whole scheme. However I could not
   comprehend the intent of _source, _destination. In particular cases they can
   be mail-id, server-id; some kind of classes. They need not be necessarily
   std::string.
   2. basic_message<...> should be serializable over asio sockets.
   3. There can be derived classes from basic_message<...> ---
   basic_receiver_message<...>, basic_sender_message<...>. For
   basic_receiver_message we can have functions like:-
   read(socket&,basic_receiver_message<...>&) or read_until(socket&,
   basic_receiver_message<...>&). Here read_until does not contain any
   delimiter because basic_receive_message<...> will have this information.
   Similar will be the functions around basic_sender_messag<...>
   4. In future there should be modules to parse basic_message<...> using
   boost::regex or boost::spirit or boost::xpressive.


Moreover we need project branches for rtp, rtsp, also. Though yes our prime
requirement is http.

Regards,
Reetesh Mukul

Re: [cpp-netlib-devel] Some thoughts, XMPP work etc.

[Dean M. B. <mik...@gm...>]

Hi Reetesh!

On Nov 26, 2007 4:57 AM, Reetesh Mukul <ree...@gm...> wrote:

> Hi Dean and All,
>
> I have been going through the code development in cpp-netlib for last 6
> months. I have been experimenting on XMPP for a while, (http://tarang.xmpp.googlepages.com/
> ) and have done some crude implementations (see svn). With time, I am
> planning to stick to cpp-netlib codes, for their is no meaning of
> implementing things in XMPP which are already in cpp-netlib. That said, now
> onwards I will like to put my view points (and also codes in cpp-netlib ;-)
> ), for it will have direct impact on XMPP design. I have some points in my
> mind:-
>

I will take a look. Thanks for the link! I'll try to answer the questions
below:


>
>
>    1. basic_message<...> class resembles basic_string<...> class. I
>    think this class very well fits in the whole scheme. However I could not
>    comprehend the intent of _source, _destination. In particular cases they can
>    be mail-id, server-id; some kind of classes. They need not be necessarily
>    std::string.
>
> basic_message<...> should have a source and a destination, for
identification purposes. So any message should be associated with a source
and a destination. However, the use of std::string was merely for
convenience. The idea is that you should be able to change the
implementation of basic_message<...> by  supplying the appropriate template
argument tag (blob type maybe) for specialization for many different types
of messages. For example, there are messages that use integers for source
and destination, have headers that have 1:1 mapping between keys and values,
etc.

>
>    1.
>    2. basic_message<...> should be serializable over asio sockets.
>
> This can actually be implemented independent of a basic_message, or as a
decorator to the type. Therefore, there could be a wrapper type
serializable<...> which takes a template argument of type
basic_message<...>, which decorates the type basic_message<...> through
inheritance.

>
>    1.
>    2. There can be derived classes from basic_message<...> ---
>    basic_receiver_message<...>, basic_sender_message<...>. For
>    basic_receiver_message we can have functions like:-
>    read(socket&,basic_receiver_message<...>&) or read_until(socket&,
>    basic_receiver_message<...>&). Here read_until does not contain any
>    delimiter because basic_receive_message<...> will have this information.
>    Similar will be the functions around basic_sender_messag<...>
>
> This makes sense. However, all this boilerplate can be implemented in the
adapters layer, to turn basic_message<...> types into streamable or
iteratable streams. More about this when they crystallize in my mind.


>
>    1.
>    2. In future there should be modules to parse basic_message<...>
>    using boost::regex or boost::spirit or boost::xpressive.
>
> We've already started with a simple (very crude, possibly wrong) parser
for HTTP message handling.

>
>    1.
>
>
> Moreover we need project branches for rtp, rtsp, also. Though yes our
> prime requirement is http.


Either we branch, or we just implement the protocols independent of the
structure.

Thank you very much, and I hope the above explanations make sense!

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
[http://cplusplus-soup.blogspot.com/]
[mik...@gm...]
[+63 928 7291459]
[+1 408 4049523]

Re: [cpp-netlib-devel] Some thoughts, XMPP work etc.

[Reetesh M. <ree...@gm...>]

Sorry for late reply.

 I may be wrong completely, nevertheless can't the socket on which we are
sending data can keep track of all messages (received or sent) by using some
kind of hash_map/multiindex. After all complete identity of a message over
network depends on who sends it and who receives it. If one needs to keep
this track there can be provision of a table <sender, receiver, message&>

Regards,
Reetesh Mukul

Re: [cpp-netlib-devel] Some thoughts, XMPP work etc.

[Dean M. B. <mik...@gm...>]

On Nov 30, 2007 7:03 PM, Reetesh Mukul <ree...@gm...> wrote:
> Sorry for late reply.
>
>  I may be wrong completely, nevertheless can't the socket on which we are
> sending data can keep track of all messages (received or sent) by using some
> kind of hash_map/multiindex. After all complete identity of a message over
> network depends on who sends it and who receives it. If one needs to keep
> this track there can be provision of a table <sender, receiver, message&>
>

I don't think storing messages should be the concern of the networking
library. If the client code wants to store messages, they should have
to do it using their own strategy. The networking library should
facilitate the transfer of data, but not the management of
sent/received messages.

And no, I don't think a message that came from the same socket
necessarily have to come from the same source. Consider HTTP messages
that came through a single HTTP proxy, but were retrieved from a
different source website. Actually, in all cases a message should be
associated with a source and destination regardless of the actual
channel from which it came: consider a message that may come from a
file (email, XML, etc.) which can be associated with a source (email
address, URI, etc) and a destination (email address, ip address,
etc.), but can be transferred through many different means (via TCP/IP
sockets, UNIX domain sockets, UDP, etc.).

So state management should not be within the scope of the networking
library -- anything related to application specific logic should be
application specific.

I hope this makes sense.

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
[http://cplusplus-soup.blogspot.com/]
[mik...@gm...]
[+63 928 7291459]
[+1 408 4049523]

Re: [cpp-netlib-devel] Some thoughts, XMPP work etc.

[Reetesh M. <ree...@gm...>]

Yes now I got it. Actually I was thinking in different way. Suppose I have a
http socket (which is on top of TCP socket), then one way to use it will be,

http h("www.boost.org");
h >> receive_msg;

Here h does not implies the inherent socket, it implies that h is the source
of message, a kind of node. Ofcourse this means we need to keep information
to track data source of receive_msg. Also your http_proxy example points
towards need of sender,receiver in message class. Still I feel we may need
to have empty structures for sender, receiver in some case; through some
template parameters.

I will keep paradigm of cpp-network for xmpp library also.

Regards,
Reetesh Mukul

On 11/30/07, Dean Michael Berris <mik...@gm...> wrote:
>
> On Nov 30, 2007 7:03 PM, Reetesh Mukul <ree...@gm...> wrote:
> > Sorry for late reply.
> >
> >  I may be wrong completely, nevertheless can't the socket on which we
> are
> > sending data can keep track of all messages (received or sent) by using
> some
> > kind of hash_map/multiindex. After all complete identity of a message
> over
> > network depends on who sends it and who receives it. If one needs to
> keep
> > this track there can be provision of a table <sender, receiver,
> message&>
> >
>
> I don't think storing messages should be the concern of the networking
> library. If the client code wants to store messages, they should have
> to do it using their own strategy. The networking library should
> facilitate the transfer of data, but not the management of
> sent/received messages.
>
> And no, I don't think a message that came from the same socket
> necessarily have to come from the same source. Consider HTTP messages
> that came through a single HTTP proxy, but were retrieved from a
> different source website. Actually, in all cases a message should be
> associated with a source and destination regardless of the actual
> channel from which it came: consider a message that may come from a
> file (email, XML, etc.) which can be associated with a source (email
> address, URI, etc) and a destination (email address, ip address,
> etc.), but can be transferred through many different means (via TCP/IP
> sockets, UNIX domain sockets, UDP, etc.).
>
> So state management should not be within the scope of the networking
> library -- anything related to application specific logic should be
> application specific.
>
> I hope this makes sense.
>
> --
> Dean Michael C. Berris
> Software Engineer, Friendster, Inc.
> [http://cplusplus-soup.blogspot.com/]
> [mik...@gm...]
> [+63 928 7291459]
> [+1 408 4049523]
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell.  From the desktop to the data center, Linux is going
> mainstream.  Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>

Re: [cpp-netlib-devel] Some thoughts, XMPP work etc.

[Dean M. B. <mik...@gm...>]

Hi Reetesh,

On Dec 1, 2007 2:07 AM, Reetesh Mukul <ree...@gm...> wrote:
> Yes now I got it. Actually I was thinking in different way. Suppose I have a
> http socket (which is on top of TCP socket), then one way to use it will be,
>
> http h("www.boost.org ");
> h >> receive_msg;
>
> Here h does not implies the inherent socket, it implies that h is the source
> of message, a kind of node.

This idiom, although very well meant, does not really apply to the
networking concept. Here's a couple of reasons why:

1. The istream/ostream family of objects in the STL are sources of raw
data -- they do not by any means perform any special processing on the
data except for formatting or conversion. This makes the underlying
implementation simple and considerably light (or cannot be made any
lighter).

2. The above construct doesn't show the protocol specific method of
retrieving the message. In HTTP you have a myriad of requests and
replies. For example, does the above sample imply a 'GET' request?
What if you want to perform a 'POST' request, how do you construct
your stream then? For example, you want to use a persistent connection
(HTTP 1.1) and want to send 'GET' and 'POST' requests over the same
connection, would that be possible with the above construct? Even for
SMTP this idiom will not work because you have a myriad of requests
and replies that simply slapping a stream on top of a connection
doesn't solve the problem.

The way I chose to implement this was with an explicit 'Client'
object, which specifies protocol specific methods precisely for
getting and sending messages over an implicit channel. In the latest
version from trunk, you should be able to see the intended idiom,
which looks like the following:

    using namespace boost::network;
    http::request request("http://boost.org/");
    http::client client_;
    http::response response_;
    response_ = client_.get(request);

This can easily be extended so that the following will also be
consistent with the interface:

    using namespace boost::network;
    http::request request("http://boost.org/");
    http::client client_;
    http::response response_;
    std::map<std::string, std::string> post_map;
    post_map["username"] = "me";
    post_map["password"] = "my_password";
    response_ = client_.post(request, post_map);

We can even implement the 'PUT' and 'DELETE' methods for HTTP, for a
REST aware client.

> Ofcourse this means we need to keep information
> to track data source of receive_msg. Also your http_proxy example points
> towards need of sender,receiver in message class. Still I feel we may need
> to have empty structures for sender, receiver in some case; through some
> template parameters.
>

You can currently actually do this in the cpp-netlib -- you can create
your own message specialization by using the tag parameter of the
basic_message type.

> I will keep paradigm of cpp-network for xmpp library also.
>

If you still have questions about the intended design, please keep the
questions and suggestions coming.

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
[http://cplusplus-soup.blogspot.com/]
[mik...@gm...]
[+63 928 7291459]
[+1 408 4049523]