cpp-netlib-devel — Developers Mailing List

Re: [cpp-netlib-devel] FW: body copies on http::client::post

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

On Thu, Oct 21, 2010 at 3:01 AM, Nelson, Erik - 2
<eri...@ba...> wrote:
>> Kim Gräsman wrote on Wednesday October 20, 2010 2:41 PM
>
>> Microsoft's STL as of VS2008 doesn't use COW, it uses the small-string
>> optimization. Not sure if they went (back?) to COW in 2010, but I
>> doubt it.
>>
>> LLVM has an interesting sub-project implementing a standard library
>> from scratch, and one of the decisions they mention in the overview is
>> using small string optimization over COW, as if it was a plain truth;
>> http://libcxx.llvm.org/.
>>
>> So, I think there's merit to not expecting COW from std::string.
>>
>
> STLPort (ships with Sun C++ compilers) doesn't use COW, either.
>
> http://stlport.sourceforge.net/
>
> and the links I put in a previous post
>
> http://bit.ly/hiqqU
> http://bit.ly/cqpKVN
>
> have indications in the discussions that gcc may move away from COW
> in the future.
>

Yep.

> Visual Studio 6.0 had well-known thread-safety bugs in its COW
> std::string implementation, and was the last version of MSVC to
> use COW, according to my understanding.
>
> http://support.microsoft.com/kb/813810
> http://www.eggheadcafe.com/software/aspnet/32308437/-thread-safe-stl-for-vc60.aspx
>

Ah, I stand corrected then. :)

That's good to know, I'll fix that most probably in 0.9 -- unless
someone else beats me to it and sends a pull request for 0.8-devel. :)

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] FW: body copies on http::client::post

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

On Wed, Oct 20, 2010 at 11:26 PM, Nelson, Erik - 2
<eri...@ba...> wrote:
>>Dean Michael Berris wrote on Wednesday, October 20, 2010 8:40 AM
>
>>> Erik Nelson wrote:
>>> std::strings are actually terrible buffers if you're manipulating
>>> binary objects, at least in our project.
>>
>> Hmmm... why? Binary buffers are just thunks of memory, and you can
>> always get the .data() of std::string objects.
>>
>
> Think about what you'd have to do to store and manipulate an array
> of doubles in a string, referencing it through the .data() member.
> vector<double> seems like a much more natural fit
>

You can do that, you just have to re-interpret the pointer from a char
* to a double *. Alignment issues aside, this is possible to do.

Besides, you can't send a vector<double> through a socket, you need a
char* so you're going to reinterpret the other way around.

>>> If we have a big memory
>>> region that's full of POD and want to send it across the wire,
>>> making a std::string out of it means *yet another* copy.  That's why
>>> the asio buffer interface is in no way std::string-centric.
>>
>> Sure, but Asio requires that everything you want to send *is* in
>> memory. Whether it's a string or just a range, well as far as Asio is
>> concerned it'd have to be in memory to be sent. cpp-netlib is built to
>> make simple things easy really. ;)
>
> It's fine to have it in memory... just not copies of it.
> Simple things *should* be easy.  I'm not sure that means there needs
> to be multiple copies made of the payload.
>

The easiest thing that can possibly work is to make copies of the data
to help with threading (as already mentioned before) and to delineate
where the application's data ends and where cpp-netlib's data starts.

>>
>> If you really need zero-copy messages, that would require that you
>> pass in pointers to the data, and make sure that they're "live" when
>> cpp-netlib starts requiring the data.
>
> That's how asio works, right?  The buffers are pointers, and the app
> needs to make sure they have not been invalidated;
>

Asio needs a char * buffer last I checked. Actually, it's generic on
the buffer types, but there is a concept of a ConstBuffer in Asio that
requires certain things.

>>
>> You have two choices here:
>>
>> 1) Implement it yourself, use the concepts and make a "better" message
>> type, and send a pull request. :)
>>
>> 2) Wait until I (or someone else) gets around to fixing that part of
>> the implementation. :)
>>
>
> Understood, just wanted to throw the issue into the design discussion.
>

1 is easy to do as it is now, it's even possible to make the request
objects just POD types -- which I intend to do also -- to allow for
use cases where they're just data holders.

>>>
>>> That sounds great!  When you say that cpp-netlib will 'conserve' the
>>> ranges/buffers, what does that mean?
>>>
>
>> That means, only when data is going to be sent will data be
>> "linearized" to a fixed-size buffer that gets re-used every time a
>> write is going to be attempted. Asio has the async_read and
>> async_write functions that take non-mutable buffers, and at this time
>> ranges don't count as buffers.
>>
>> This is going to be helpful in the case when files are going to be
>> served, and the possibility of having mmap'ed files/buffers can be
>> expressed as a range of iterators. The data can even be non-linear, it
>> can be a range of joined iterators, it can be a range of function
>> input iterators, but the data will be linearized still to a fixed-size
>> buffer for Asio's consumption.
>>
>
> Does asio require linearized data?
>

Yep, it needs the data to be a contiguous thunk of memory.

>> Until Asio has a way of dealing with Boost.Ranges on its own, the
>> linearization will have to be done by cpp-netlib. At the worst case,
>> there will be a fixed overhead which will be caused by a buffer for
>> each connection.
>>
>
> I think we might just disagree on this point, but, in my view, this
> linearization is a core problem since it will cause a complete
> memory copy of anything that is sent (unless I'm missing something).

Well, unless you just keep re-using a buffer of 4kb over and over --
then the overhead will be a fixed 4kb of memory. It doesn't matter how
large your data range is, it just matters that data is sent through
the socket 4kb at a time. This means you only ever linearize 4kb of
memory every time.

> That's fine if you're serving up 1 MB of something, but a problem
> if you're serving up 50 GB of something.  This design will preclude
> a typical Windows 32-bit program from serving files larger than
> 1 or 2 GB, right?
>

Nope, this won't. Like I point out above, writing just 4kb of data (a
default page's size in Linux) at a time will only linearize 4kb of
data for every write. You can serve however large file you want.

Also, the server will not have this problem in 0.8 because I will
allow for handlers to do the writing asynchronously -- so the handlers
can figure out how much data it wants to serve as chunks at a time,
and they get a chance to write it out on their own.

On the client side, having a message type that is a POD and supports
ranges allows for more demanding applications (that serve huge amounts
of data) to supply ranges instead, which the client will linearize
into fixed-sized buffers to be written for every write.

> Is Boost.Range on the roadmap for asio?
>

I don't think so, no. It's trivial to linearize ranges into a
Boost.Array anyway, and hand Boost.Asio the Boost.Array pointer and
the size of the data in the Boost.Array to write out to the socket.

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] FW: body copies on http::client::post (was: RE: Poll: Next Features to Implement)

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

On Thu, Oct 21, 2010 at 2:41 AM, Kim Gräsman <kim...@gm...> wrote:
> Hi Dean,
>
> On Wed, Oct 20, 2010 at 14:39, Dean Michael Berris
> <mik...@gm...> wrote:
>>>
>>>
>>> I'm unconvinced that COW strings can be depended on as a central
>>> library feature- a quick Google seems to indicate otherwise.
>>>
>>> http://bit.ly/hiqqU
>>> http://bit.ly/cqpKVN
>>>
>>
>> cpp-netlib doesn't depend on COW, but most implementations do
>> implement std::string with COW optimizations. This means, GNU's
>> libstdc++ has a COW string, Dinkumware (now Microsoft's STL)
>> implements it as well. Worrying about copies only matters if it's
>> really affecting the performance of the application.
>
> Microsoft's STL as of VS2008 doesn't use COW, it uses the small-string
> optimization. Not sure if they went (back?) to COW in 2010, but I
> doubt it.
>

Oh, then my info on MS STL would still be pre-2008. Thanks for the
update. I learn something new everyday. :D

> LLVM has an interesting sub-project implementing a standard library
> from scratch, and one of the decisions they mention in the overview is
> using small string optimization over COW, as if it was a plain truth;
> http://libcxx.llvm.org/.
>

Yeah, I've been following that too. That's interesting, although that
will be a C++0x standard library. I don't want to wait for C++0x to
come along to make my life a lot easier in implementing cpp-netlib. :D

> So, I think there's merit to not expecting COW from std::string.
>

Yup, but I haven't been writing cpp-netlib to expect COW. I just think
that removing copies can be done later on. ;)

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] FW: body copies on http::client::post

[Nelson, E. - 2 <eri...@ba...>]

> Kim Gräsman wrote on Wednesday October 20, 2010 2:41 PM
 
> Microsoft's STL as of VS2008 doesn't use COW, it uses the small-string
> optimization. Not sure if they went (back?) to COW in 2010, but I
> doubt it.
> 
> LLVM has an interesting sub-project implementing a standard library
> from scratch, and one of the decisions they mention in the overview is
> using small string optimization over COW, as if it was a plain truth;
> http://libcxx.llvm.org/.
> 
> So, I think there's merit to not expecting COW from std::string.
>

STLPort (ships with Sun C++ compilers) doesn't use COW, either.

http://stlport.sourceforge.net/

and the links I put in a previous post

http://bit.ly/hiqqU
http://bit.ly/cqpKVN

have indications in the discussions that gcc may move away from COW
in the future.

Visual Studio 6.0 had well-known thread-safety bugs in its COW
std::string implementation, and was the last version of MSVC to
use COW, according to my understanding.

http://support.microsoft.com/kb/813810
http://www.eggheadcafe.com/software/aspnet/32308437/-thread-safe-stl-for-vc60.aspx


Erik

----------------------------------------------------------------------
This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. 
Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. 
The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. 

References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: 
http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.

Re: [cpp-netlib-devel] FW: body copies on http::client::post (was: RE: Poll: Next Features to Implement)

[Kim G. <kim...@gm...>]

Hi Dean,

On Wed, Oct 20, 2010 at 14:39, Dean Michael Berris
<mik...@gm...> wrote:
>>
>>
>> I'm unconvinced that COW strings can be depended on as a central
>> library feature- a quick Google seems to indicate otherwise.
>>
>> http://bit.ly/hiqqU
>> http://bit.ly/cqpKVN
>>
>
> cpp-netlib doesn't depend on COW, but most implementations do
> implement std::string with COW optimizations. This means, GNU's
> libstdc++ has a COW string, Dinkumware (now Microsoft's STL)
> implements it as well. Worrying about copies only matters if it's
> really affecting the performance of the application.

Microsoft's STL as of VS2008 doesn't use COW, it uses the small-string
optimization. Not sure if they went (back?) to COW in 2010, but I
doubt it.

LLVM has an interesting sub-project implementing a standard library
from scratch, and one of the decisions they mention in the overview is
using small string optimization over COW, as if it was a plain truth;
http://libcxx.llvm.org/.

So, I think there's merit to not expecting COW from std::string.

- Kim

Re: [cpp-netlib-devel] FW: body copies on http::client::post

[Nelson, E. - 2 <eri...@ba...>]

>Dean Michael Berris wrote on Wednesday, October 20, 2010 8:40 AM

>> Erik Nelson wrote:
>> std::strings are actually terrible buffers if you're manipulating
>> binary objects, at least in our project.
> 
> Hmmm... why? Binary buffers are just thunks of memory, and you can
> always get the .data() of std::string objects.
> 

Think about what you'd have to do to store and manipulate an array
of doubles in a string, referencing it through the .data() member.
vector<double> seems like a much more natural fit

>> If we have a big memory
>> region that's full of POD and want to send it across the wire,
>> making a std::string out of it means *yet another* copy.  That's why
>> the asio buffer interface is in no way std::string-centric.
> 
> Sure, but Asio requires that everything you want to send *is* in
> memory. Whether it's a string or just a range, well as far as Asio is
> concerned it'd have to be in memory to be sent. cpp-netlib is built to
> make simple things easy really. ;)

It's fine to have it in memory... just not copies of it.
Simple things *should* be easy.  I'm not sure that means there needs
to be multiple copies made of the payload.

> 
> If you really need zero-copy messages, that would require that you
> pass in pointers to the data, and make sure that they're "live" when
> cpp-netlib starts requiring the data.

That's how asio works, right?  The buffers are pointers, and the app
needs to make sure they have not been invalidated;

> 
> You have two choices here:
> 
> 1) Implement it yourself, use the concepts and make a "better" message
> type, and send a pull request. :)
> 
> 2) Wait until I (or someone else) gets around to fixing that part of
> the implementation. :)
> 

Understood, just wanted to throw the issue into the design discussion.

>>
>> That sounds great!  When you say that cpp-netlib will 'conserve' the
>> ranges/buffers, what does that mean?
>>
 
> That means, only when data is going to be sent will data be
> "linearized" to a fixed-size buffer that gets re-used every time a
> write is going to be attempted. Asio has the async_read and
> async_write functions that take non-mutable buffers, and at this time
> ranges don't count as buffers.
> 
> This is going to be helpful in the case when files are going to be
> served, and the possibility of having mmap'ed files/buffers can be
> expressed as a range of iterators. The data can even be non-linear, it
> can be a range of joined iterators, it can be a range of function
> input iterators, but the data will be linearized still to a fixed-size
> buffer for Asio's consumption.
> 

Does asio require linearized data?

> Until Asio has a way of dealing with Boost.Ranges on its own, the
> linearization will have to be done by cpp-netlib. At the worst case,
> there will be a fixed overhead which will be caused by a buffer for
> each connection.
>

I think we might just disagree on this point, but, in my view, this
linearization is a core problem since it will cause a complete
memory copy of anything that is sent (unless I'm missing something).
That's fine if you're serving up 1 MB of something, but a problem
if you're serving up 50 GB of something.  This design will preclude
a typical Windows 32-bit program from serving files larger than
1 or 2 GB, right?

Is Boost.Range on the roadmap for asio?

Erik



----------------------------------------------------------------------
This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. 
Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. 
The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. 

References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: 
http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.

Re: [cpp-netlib-devel] FW: body copies on http::client::post (was: RE: Poll: Next Features to Implement)

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

Hi Erik,

I apologize for not responding fast enough to this message. Google
insists that email from you is spam. :(

On Tue, Oct 19, 2010 at 11:55 PM, Nelson, Erik - 2
<eri...@ba...> wrote:
>
>>Dean Michael Berris wrote on Tuesday, October 19, 2010 11:26 AM
>>
>> Actually, Asio does. It requires that you give it a set of buffers --
>> and std::string objects qualify as good buffers -- to write out to the
>> sockets.
>
> The asio buffers can't be strings, right?

They can be.

> As I understand it, asio
> buffers are simply pointers into contiguous memory regions, and
> std::string is only one of many types that hold contiguous memory
> regions (and is in no way preferred).
> http://bit.ly/dubjW5
>

Yup, my point wasn't that they're required to be std::string. Heck, we
can use C strings but they're much more cumbersome to deal with and
are just much uglier than std::string.

>
> std::strings are actually terrible buffers if you're manipulating
> binary objects, at least in our project.

Hmmm... why? Binary buffers are just thunks of memory, and you can
always get the .data() of std::string objects.

You can use a Boost.Array and you'd have a good enough statically
sized buffer with iterator semantics, but that's not what the message
objects are meant to model. Also, it's possible to implement a
basic_message<> specialization that uses an internal linked-list of
Boost.Array's but, well nobody's asked for that yet.

Actually, it's even possible to make the body be just a range as I
explained in the previous email.

> If we have a big memory
> region that's full of POD and want to send it across the wire,
> making a std::string out of it means *yet another* copy.  That's why
> the asio buffer interface is in no way std::string-centric.
>

Sure, but Asio requires that everything you want to send *is* in
memory. Whether it's a string or just a range, well as far as Asio is
concerned it'd have to be in memory to be sent. cpp-netlib is built to
make simple things easy really. ;)

>> Also, if you have an std::string implementation that implements
>> copy-on-write semantics, then you don't pay for a 50GB copy because a
>> copy is pretty much just a single pointer copy anyway. Most, if not
>> all implementations of std::string do the COW optimization precisely
>> because of the overhead of copying strings around even if you don't
>> modify them.
>>
>
> I'm unconvinced that COW strings can be depended on as a central
> library feature- a quick Google seems to indicate otherwise.
>
> http://bit.ly/hiqqU
> http://bit.ly/cqpKVN
>

cpp-netlib doesn't depend on COW, but most implementations do
implement std::string with COW optimizations. This means, GNU's
libstdc++ has a COW string, Dinkumware (now Microsoft's STL)
implements it as well. Worrying about copies only matters if it's
really affecting the performance of the application.

If you really need zero-copy messages, that would require that you
pass in pointers to the data, and make sure that they're "live" when
cpp-netlib starts requiring the data. At this point, it is entirely
possible to optimize the cpp-netlib to use messages that use a single
buffer, with just ranges of iterators defining which parts of the
buffer is the source, destination, etc. but managing these buffers and
the ranges are quite a challenge in themselves.

> I'm not sure I fully buy into the 'the-optimizer-will-cover-it-up'
> argument, either.  The optimizer covers up very little in debug
> mode and a program that can't be well exercised in debug mode is
> hard to... debug.  The speed will be slower, but having the
> memory footprint explode just due to the networking library is
> a bitter pill to swallow.
>

There's no "the optimizer will cover it up" here. It's just that most
std::string implementations  (that I know) use COW so there's nothing
to worry about there. Now if you use a different string
implementation, then maybe you will need to avoid it (not sure if
Apache's STL implements COW for strings) or you'd implement your own
message type that works well with cpp-netlib. :)

You have two choices here:

1) Implement it yourself, use the concepts and make a "better" message
type, and send a pull request. :)

2) Wait until I (or someone else) gets around to fixing that part of
the implementation. :)

>> At any rate, the next version will have a message type that supports
>> ranges for bodies. This allows for a means of making the body of a
>> request a Boost.Range compatible range -- so an input_iterator range
>> would work fine in that version. In that case data will be pulled from
>> input iterator ranges, and cpp-netlib can conserve the buffers as they
>> come.
>>
>
> That sounds great!  When you say that cpp-netlib will 'conserve' the
> ranges/buffers, what does that mean?
>

That means, only when data is going to be sent will data be
"linearized" to a fixed-size buffer that gets re-used every time a
write is going to be attempted. Asio has the async_read and
async_write functions that take non-mutable buffers, and at this time
ranges don't count as buffers.

This is going to be helpful in the case when files are going to be
served, and the possibility of having mmap'ed files/buffers can be
expressed as a range of iterators. The data can even be non-linear, it
can be a range of joined iterators, it can be a range of function
input iterators, but the data will be linearized still to a fixed-size
buffer for Asio's consumption.

Until Asio has a way of dealing with Boost.Ranges on its own, the
linearization will have to be done by cpp-netlib. At the worst case,
there will be a fixed overhead which will be caused by a buffer for
each connection.

HTH

(Also, I hope Google doesn't treat your mail as Spam again)

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] FW: body copies on http::client::post (was: RE: Poll: Next Features to Implement)

[Nelson, E. - 2 <eri...@ba...>]

>Dean Michael Berris wrote on Tuesday, October 19, 2010 11:26 AM

>>Erik Nelson wrote:
>> The copying is pretty key... if I'm sending a 50GB message, I really
>> can't afford to have any copies besides the one that is the source.
>>
 
> You can do without copies if you create a message with the data in the
> body already. You also don't need to use the post interface that
> doesn't include the body and content-type.
> 
>> The design itself ought not impose unnecessary runtime
>> overhead in either the time or memory usage domains.  If I
>> understand it correctly, the asio lib doesn't require the message
>> to be marshaled in memory as a contiguous string, and neither
>> should netlib, in my opinion.
>>
 
> Actually, Asio does. It requires that you give it a set of buffers --
> and std::string objects qualify as good buffers -- to write out to the
> sockets.

The asio buffers can't be strings, right?  As I understand it, asio
buffers are simply pointers into contiguous memory regions, and
std::string is only one of many types that hold contiguous memory
regions (and is in no way preferred).
http://bit.ly/dubjW5


std::strings are actually terrible buffers if you're manipulating
binary objects, at least in our project.  If we have a big memory
region that's full of POD and want to send it across the wire,
making a std::string out of it means *yet another* copy.  That's why
the asio buffer interface is in no way std::string-centric.

> Also, if you have an std::string implementation that implements
> copy-on-write semantics, then you don't pay for a 50GB copy because a
> copy is pretty much just a single pointer copy anyway. Most, if not
> all implementations of std::string do the COW optimization precisely
> because of the overhead of copying strings around even if you don't
> modify them.
> 

I'm unconvinced that COW strings can be depended on as a central
library feature- a quick Google seems to indicate otherwise.

http://bit.ly/hiqqU
http://bit.ly/cqpKVN

I'm not sure I fully buy into the 'the-optimizer-will-cover-it-up'
argument, either.  The optimizer covers up very little in debug
mode and a program that can't be well exercised in debug mode is
hard to... debug.  The speed will be slower, but having the
memory footprint explode just due to the networking library is
a bitter pill to swallow.

> At any rate, the next version will have a message type that supports
> ranges for bodies. This allows for a means of making the body of a
> request a Boost.Range compatible range -- so an input_iterator range
> would work fine in that version. In that case data will be pulled from
> input iterator ranges, and cpp-netlib can conserve the buffers as they
> come.
> 

That sounds great!  When you say that cpp-netlib will 'conserve' the
ranges/buffers, what does that mean?

Erik

----------------------------------------------------------------------
This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. 
Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. 
The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. 

References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: 
http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.

[cpp-netlib-devel] New Tag System

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

Hi Everyone,

I just wanted to shed some light into the new tag system that came out
in cpp-netlib 0.7 and will be enhanced as 0.8-devel prorgesses.
Earlier I did a quick refactor and move out of the HTTP specific tags
from boost/network/tags.hpp into boost/network/protocol/http/tags.hpp
-- this change (http://goo.gl/O0zF) is a singular change that affects
a lot of files and applies cleanly to 0.7 as well.

The new tag system relies on Boost.MPL to aid with what I'd like to
call "Tag Calculus". Let me elaborate on this a little.

First, tags are now defined using an inheritance structure. There are
what I'd like to call "root tags" from which all meaningful tags
derive their meaning from. To model this inheritance structure we use
Boost.MPL vectors to determine which root tags a given tag derives
from. An example from the library is the
`http_default_8bit_udp_resolve` tag. The ingredients for this tag are
as follows:

  typedef mpl::vector<http, default_string, simple, udp, sync>
http_default_8bit_udp_resolve_tags;
  BOOST_NETWORK_DEFINE_TAG(http_default_8bit_udp_resolve);

The macro BOOST_NETWORK_DEFINE_TAG does two things:

1. It creates a typedef to the inheritance structure as
`http_default_8bit_udp_resolve`. This uses Boost.MPL's
inherit_linearly algorithm and the default inheritance metafunction
that comes with Boost.MPL.

2. It also specializes the `components` metafunction that maps the tag
back to the root tags from which it derives. This means a call to:

  http::tags::components<http_default_8bit_udp_resolve>::type

Will yield the mpl::vector that is
`http_default_8bit_udp_resolve_tags`. This is handy especially if you
want to make decisions at compile time based on the composition of a
tag -- for example, an asynchronous keepalive connection
implementation may be different from an asynchronous simple connection
in the HTTP sense.

There are also some support metafunctions which allows for easy
querying of a given tag. Metafunctions like `is_sync` or `is_async`
would normally be used as part of an mpl::if_ to choose which
implementation/type should be yielded by a metafunction that is
parametric on whether a tag derives from synchronous or asynchronous.

If you notice that the compile times are growing long, this may be
explained by the tag calculus that's now in place in cpp-netlib. In
the coming couple of weeks I look to being able to address the
compile-time issue with precompiled headers and other tricks to make
cpp-netlib not that much of a pain to use as far as compile time goes,
but there's definitely room for optimization there.

Also, the tag calculus may be greatly simplified if we kept the tags
as mpl::vectors instead of using the inheritance structure, although
tag dispatching based on the root tags might be affected. At this time
we don't use tag dispatch based on root tags (yet) but it's something
that's worth expanding and exploring as development goes on.

Another reason for this increase in compile times is the introduction
of the Concept Checks which cause a lot more template instantiations
than if concept checking was turned off. I'm not sure if there's a way
to selectively turn off concept checking but I'm not opposed to
introducing a preprocessor macro for that.

That's it for now guys tomorrow I'll be working on the connection<>
interface and the thread pool concept/implementation to be supported
by the server implementation. Let me know if you need any more
clarification on the tag system before I proceed to changing it yet
again. :D

Have a good one everyone and I hope this helps!

-- 
Dean Michael Berris
deanberris.com

[cpp-netlib-devel] cpp-netlib 0.8 Target Deliverables

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

Hi Guys!

To those new on the mailing list, welcome -- and to those who have
been lurking or wanting to contribute to the effort but find it really
hard this lack of direction, then here's your chance.

As most of you already know I'm working on cpp-netlib full-time now.
No I still don't have work, so I'm making use of my time in between
finding work to work on cpp-netlib and move it closer to something
worth submitting into Boost by December this year (yes, 2010). So I'm
sending my Google Task list for cpp-netlib to the list so everyone
knows what to expect from 0.8.

I'll also be creating issues and Wiki pages on the official project
repository at http://github.com/cpp-netlib/cpp-netlib. From now on,
only experimental "work-in progress" stuff goes onto my repository
(and those pull requests from others who want to join the effort
should still be sent to my repository) while the "stable" and
"milestone" achievements get pushed to the official repo as soon as
they are done.

If you have any questions or would like clarifications, please feel
free to send them in through the mailing list. :D

--8<-----------

Release 0.8 -- Target is 1st Week of November
	Integrate XMPP Implementation from Glyn
	Refactor HTTP Client Constructor to use Boost.Parameter
	Callback thread pool
		Configurable number of threads
		Taken in as constructor parameter to asynchronous HTTP clients
	Implement Callback-based HTTP Client API
	Streaming HTTP Client API
		Implement a basic_response<> which has a boost::asio::iostream bound
to a socket for the body
		Implement a basic_request<> which has a stream for the body
		client.get(request, callback) where callback is of signature
void(basic_response<Tag>)
		client.put(request) where body(request) models an InputStream
	Server Handler Facade
		CRTP to provide default implementation for PUT, POST, GET, and HEAD handlers
		Simplify parameter and header parsing
		Simplify parameter validation and requirement specification
	Web Service Framework
		Dynamic Handler Registration
		Path Routing (regex)
		Request Normalization
	HTTP Server Handler Work Pool
		Implement a work pool to handle requests
		Implement a basic_request<> that has a stream for the body
		Implement a http_connection<> that exposes asynchronous routines for output
			Expose a set_headers function that takes a range of
pair<string,string> elements and writes that out through the HTTP
connection
			Expose a write function that takes a range as input and
asynchronously sends the data through the HTTP connection
			Expose a close function that closes the connection from the server's end
	Implement a basic_server<> that requires the handler type to override
the function call operator and take a basic_request<> and an
http_connection<> as parameters

--8<-----------------

As always, thanks again for the support and I look forward to your
contributions to release 0.8.

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] [network] cpp-netlib 0.7 released!

[Glyn M. <gly...@gm...>]

On 17 October 2010 14:34, Dean Michael Berris <mik...@gm...>wrote:

> Hi Everyone!
>
> So, I've been busy the past few hours doing a final push to get 0.7
> out the door so that starting tomorrow I can start working on the 0.8
> branch to improve the server-side HTTP implementation. Now, it's
> official, 0.7 is out the door and is ready for prime-time. ;-)
>
> In case you'd like to try it out, it's header only and you can
> download the 0.7 release from:
>
>  http://github.com/cpp-netlib/cpp-netlib/downloads
>
> This has numerous improvements and enhancements over the 0.6 version,
> and has a more robust definition of the concepts included in the
> library. Now anybody can start extending cpp-netlib with their own
> protocol implementations using the common message type. If you want
> your work to integrate cleanly with the project, you can go ahead and
> fork my repository (as the project's "benevolent dictator for life")
> and submit pull requests in case you want to get your
> implementation/fixes/extensions into the main library distribution.
>
> As earlier stated, 0.8 will be a server-side focused development
> effort which will include a lot of cool things not just an improved
> HTTP server interface. If you'd like to discuss the effort or join the
> development, please feel free to send email to either the Boost
> Developer mailing list (because this library will be submitted for
> review and inclusion in Boost around December 2010) or the cpp-netlib
> developers mailing list.
>
>
Allow me to add that the account http://github.com/cpp-netlib is now
registered as an organisation, for anyone wishing to follow this project,
and the full 0.7 documentation is now available at
http://cpp-netlib.github.com.

Glyn

[cpp-netlib-devel] [network] cpp-netlib 0.7 released!

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

Hi Everyone!

So, I've been busy the past few hours doing a final push to get 0.7
out the door so that starting tomorrow I can start working on the 0.8
branch to improve the server-side HTTP implementation. Now, it's
official, 0.7 is out the door and is ready for prime-time. ;-)

In case you'd like to try it out, it's header only and you can
download the 0.7 release from:

  http://github.com/cpp-netlib/cpp-netlib/downloads

This has numerous improvements and enhancements over the 0.6 version,
and has a more robust definition of the concepts included in the
library. Now anybody can start extending cpp-netlib with their own
protocol implementations using the common message type. If you want
your work to integrate cleanly with the project, you can go ahead and
fork my repository (as the project's "benevolent dictator for life")
and submit pull requests in case you want to get your
implementation/fixes/extensions into the main library distribution.

As earlier stated, 0.8 will be a server-side focused development
effort which will include a lot of cool things not just an improved
HTTP server interface. If you'd like to discuss the effort or join the
development, please feel free to send email to either the Boost
Developer mailing list (because this library will be submitted for
review and inclusion in Boost around December 2010) or the cpp-netlib
developers mailing list.

Thanks to everyone who's expressed interest, and those who have
offered suggestions on the improvements to be made to the library.

I hope everyone had a great weekend too!

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Building a FastCGI-compliant HTTP server with cpp-netlib

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

Hey Paolo!

On Fri, Oct 15, 2010 at 10:27 AM, Paolo Falcone <pfa...@fr...> wrote:
> Hi:
>
> I would like to ask if cpp-netlib has enough facilities to build a
> FastCGI-compliant HTTP server that can talk HTTP/1.1 both at the
> front-end and back-end?

The FastCGI protocol is interesting to implement. It should be doable
by implementing the FastCGI protocol in a handler, which talks to
FastCGI providers.

> My day job's upcoming requirements aside, this
> will be a very nice to have server, essentially a better nginx (as it
> only talks HTTP/1.0 at the backend, ruling out its use as a front-end
> server to application servers like Tomcat/Glassfish), and will be very
> attractive also to users deploying web applications on memory-starved
> VPS's.
>

Maybe you need a reverse proxy? If that is the case I would say
cpp-netlib is more than capable of providing that.

For FastCGI, a fastcgi binding would be really nice to have. Maybe
others in the list have information on FastCGI to help implement that?
It would be really great to have in a contrib/ folder inside of
boost/network/ to include things like these.

Thanks for posting Paolo, I hope others in the list can chime in with
their thoughts.

-- 
Dean Michael Berris
deanberris.com

[cpp-netlib-devel] Building a FastCGI-compliant HTTP server with cpp-netlib

[Paolo F. <pfa...@fr...>]

Hi:

I would like to ask if cpp-netlib has enough facilities to build a
FastCGI-compliant HTTP server that can talk HTTP/1.1 both at the
front-end and back-end? My day job's upcoming requirements aside, this
will be a very nice to have server, essentially a better nginx (as it
only talks HTTP/1.0 at the backend, ruling out its use as a front-end
server to application servers like Tomcat/Glassfish), and will be very
attractive also to users deploying web applications on memory-starved
VPS's.

-- 
Paolo Alexis Falcone

Cell: 63-917-508-4702
SIP: 1-747-467-6906
GTalk: pfalcone
YM: p.falcone
Skype: pfalcone
Gizmo5: paolo_falcone

[cpp-netlib-devel] My BoostCon 2010 Talk

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

Hey Guys!

My BoostCon 2010 talk has finally been uploaded, and can now be viewed
from http://bit.ly/cppnetlib ! Mateusz Loskot was kind enough to
create that bit.ly link to credit goes to him for that.

The talk is 53 minutes long, so grab some popcorn and I hope you enjoy
it too even if you weren't able to go to Aspen last May for BoostCon
2010.

Have a great one guys and I hope you enjoy! :)

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Documentation Push

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

On Sun, Oct 10, 2010 at 4:07 PM, Dean Michael Berris
<mik...@gm...> wrote:
>
> That's all folks, still looking forward to feedback. :)
> http://mikhailberis.github.com/cpp-netlib
>

Today I finished the description of the HTTP client implementation,
and included a table of the tags that are already in the library.
Please take a look at the (mostly re-written) HTTP implementation
page:

  http://mikhailberis.github.com/cpp-netlib/http.html

If you have any questions, please let me know so that I can address
them in the documentation.

Thanks and I'm about to finish up the documentation of other important
things, removing some TODOs and some empty parts.

Glyn, if you can send in the XMPP implementation for merging into
0.7-devel (I will have to re-arrange and move some of the HTTP-only
tags into their own headers), that would be awesome. I'll be finishing
up and tagging for release tomorrow, or as soon as we get the XMPP
implementation stabilized.

Have a good one guys and I look forward to comments/suggestions/reactions.

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] cpp-netlib: https server

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

On Wed, Oct 13, 2010 at 8:31 PM, Dean Michael Berris
<mik...@gm...> wrote:
>
>> Could you please clarify a little bit your answers?
>> 1. When you are planing to release 0.8 version of the library? Approximately
>> :)
>
> Ah, I'm finishing up 0.7 this week, and will be cleaning up a lot of
> the repetitive code with preprocessor macro's. I'm also writing a huge
> chunk of documentation regarding the HTTP client.
>

At the rate I'm going at the end of the month 0.8 should be out.
Hopefully I can get a more powerful development machine before then so
that I can get quicker into the implementation of more enhancements to
the HTTP server side of things.

>
> Thanks for trying that. In the meantime, there's no way yet to get the
> source of the request. I haven't been paying attention to the server
> implementation for a while already, and overlooked this one aspect. :/
>

And the latest in the 0.7-devel branch now has the fix. The code
should compile now. :)

You can get the tarball or zip file of the 0.7-devel branch now by
going to http://github.com/mikhailberis/cpp-netlib/tree/0.7-devel and
then clicking on the big "Downloads" button.

Thanks for letting me know of the problem and I hope this helps!

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] cpp-netlib: https server

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

On Wed, Oct 13, 2010 at 7:39 PM, Oleg Stupnikov <ost...@gm...> wrote:
> Hi Dean!
>
> Thank you for the quick response!

No worries, you're welcome. :)

> I'm sorry for e-mailing you directly - I didn't know the rules. You can
> publish our chain somewhere on your side. I'm fully agree with you we had
> better to share this information to everyone.

No problem. :)

> Could you please clarify a little bit your answers?
> 1. When you are planing to release 0.8 version of the library? Approximately
> :)

Ah, I'm finishing up 0.7 this week, and will be cleaning up a lot of
the repetitive code with preprocessor macro's. I'm also writing a huge
chunk of documentation regarding the HTTP client.

> 2. I tried the following code, but It didn't compile:
> template<typename request_t, typename response_t>
> void HttpServer_::operator() (request_t const &request, response_t
> &response)
> {
>       std::string ip_address = boost::network::source(request); // I also
> tried std::string ip_address = boost::network::source<std::string>(request);
> // but it didn't compile with another compile error
> //....

Oh boy, you're right. Are you using the latest release? It looks like
the request variable doesn't contain the source! :( I'll fix that in
0.7, which should be out within the week. If you cannot wait, I'll be
pushing a fix tonight to the 0.7-devel branch, and I'll let you know
when it's ready so that you can pull.

Thanks for trying that. In the meantime, there's no way yet to get the
source of the request. I haven't been paying attention to the server
implementation for a while already, and overlooked this one aspect. :/

>
> Thank you so much for your help!

You're welcome, and I hope I'll be able to help more in the future. :)

> With best wishes,

Thanks Oleg!

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] cpp-netlib: https server

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

Hi Oleg!

Sorry to reject your email to the mailing list, I encourage you to
join it and start the discussion on the list again. That said, I've
CC'ed the list so that others can see my response to your email too:

2010/10/13 Oleg Stupnikov <ost...@gm...>:
>
> I'm using cpp-netlib library and it looks very nice for me!

Thanks very much! :)

> There are a
> couple of questions I didn't manage to solve myself:
> 1. how to make it working as https server. I tied to google and I found some
> e-mail threads about that, but with no answers.

Ah, yes. Well, the quick answer would be that you can't do it yet with
the current version. I haven't worked on the HTTPS part of the server
yet (I have yet to write that part actually) which I hope to do in
version 0.8.

>     Could you please briefly explain me how to switch http server to https
> mode using your library?

Right now, it's not yet possible. I'll get back to you as soon as it
is possible. :)

> 2. how to get the client's IP address of a particular request?

You can do the following in your handler:

    string client_ip = source(request);

Where `request` is the request object passed into the request handler.

> Thank you so much for your help!

Thank you too and I hope this helps!

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Documentation Push

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

On Sat, Oct 9, 2010 at 12:42 PM, Dean Michael Berris
<mik...@gm...> wrote:
>
> Have a good weekend everyone!
>

So instead of trying out something in Lisp, I instead ended up hacking
at the CSS, making sure it's readable on smaller screens (i.e.
netbooks). There's not much that happened except for the addition of
some modifiers to the concept.

That's all folks, still looking forward to feedback. :)
http://mikhailberis.github.com/cpp-netlib

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Documentation Push

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

On Thu, Oct 7, 2010 at 6:41 PM, Dean Michael Berris
<mik...@gm...> wrote:
>
> Looking forward to hearing from you guys soon!
>

I've made another snapshot upload now to get more information into the
front page:

    http://mikhailberis.github.com/cpp-netlib/

I also updated the part about the HTTP server example.

    http://mikhailberis.github.com/cpp-netlib/hello_world_server.html

Thanks guys and I look forward to your comments on the new documentation.

Have a good weekend everyone!

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Documentation Push

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

On Wed, Oct 6, 2010 at 5:17 PM, Dean Michael Berris
<mik...@gm...> wrote:
> On Wed, Oct 6, 2010 at 12:50 PM, Dean Michael Berris
> <mik...@gm...> wrote:
[snip]
>
> I'll have more documentation up there more regularly. I'll pick up the
> pace later today to have more writing done and eventually have
> something proof-readable regarding the internals of the library.
>

I've just made some changes to
http://mikhailberis.github.com/cpp-netlib/tag_metafunctions.html -- if
anybody can take a look and let me know whether anything is not clear,
I'd love feedback.

Looking forward to hearing from you guys soon!

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Documentation Push

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

On Wed, Oct 6, 2010 at 12:50 PM, Dean Michael Berris
<mik...@gm...> wrote:
> On Wed, Oct 6, 2010 at 4:26 AM, Glyn Matthews <gly...@gm...> wrote:
>> Hi Dean,
>>
>> On 5 October 2010 20:36, Dean Michael Berris <mik...@gm...> wrote:
>>>
>>> Hi Everyone!
>>>
>>> It's that time again nearing the end of a development cycle, and I'm
>>> pretty much ready to get started on writing/editing documentation.
>>>
>>> So far I've updated the README file and turned it from just a simple
>>> .txt file into an .rst file, which GitHub so graciously formats for
>>> us. You can find the latest changes in the 0.7-devel branch to get an
>>> idea here: http://bit.ly/cqtQzX -- to say the least, nicer
>>> documentation would definitely go a long way IMO.
>>>
>>
>> If you got my pull request, the latest docs look like this:
>> http://glynos.github.com/cpp-netlib/
>
> Yes, and I've merged it to 0.7-devel just now. Thanks Glyn!
>
> Also, I love the peaches background! :D
>

Because hosting it on Github at the moment makes so much sense, I'm
going to be pushing whatever changes I make to the documentation for
review by everyone to this address:

  http://mikhailberis.github.com/cpp-netlib

Thanks for the idea Glyn, now there are some changes already up there
for comment. Please take a look around -- I've made changes to the
HTTP Client and Getting Started pages.

I'll have more documentation up there more regularly. I'll pick up the
pace later today to have more writing done and eventually have
something proof-readable regarding the internals of the library.

Have a good one guys and I look forward to feedback on the documentation! :)

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Documentation Push

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

On Wed, Oct 6, 2010 at 4:26 AM, Glyn Matthews <gly...@gm...> wrote:
> Hi Dean,
>
> On 5 October 2010 20:36, Dean Michael Berris <mik...@gm...> wrote:
>>
>> Hi Everyone!
>>
>> It's that time again nearing the end of a development cycle, and I'm
>> pretty much ready to get started on writing/editing documentation.
>>
>> So far I've updated the README file and turned it from just a simple
>> .txt file into an .rst file, which GitHub so graciously formats for
>> us. You can find the latest changes in the 0.7-devel branch to get an
>> idea here: http://bit.ly/cqtQzX -- to say the least, nicer
>> documentation would definitely go a long way IMO.
>>
>
> If you got my pull request, the latest docs look like this:
> http://glynos.github.com/cpp-netlib/

Yes, and I've merged it to 0.7-devel just now. Thanks Glyn!

Also, I love the peaches background! :D

> There are a lot of todo stubs, and there is a lot of room for examples.  I
> will try and provide some more interesting examples myself, and I'd like to
> encourage the cpp-netlib community (such as it is) to come up with cool
> stuff.

Hear, hear! :D

-- 
Dean Michael Berris
deanberris.com

Re: [cpp-netlib-devel] Finished Integrating HTTP Incremental Parser

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

On Wed, Oct 6, 2010 at 4:33 AM, Glyn Matthews <gly...@gm...> wrote:
> Hi Dean,
>
> On 5 October 2010 19:15, Dean Michael Berris <mik...@gm...> wrote:
>>
>> Hey Guys!
>>
>> Just an update. I'm still looking for a job, so if you've got any C++
>> jobs lying around, referrals would be greatly appreciated. I'm already
>> talking with a firm now though, but still keeping my options open.
>> Hopefully by November I'll go decide on what job to take.
>
> I hope your job search is going well.
>

Yes, going well enough I suppose. Thanks Glyn. :)

>>
>> Anyway, more information in-lined below.
>>
>> On Wed, Sep 29, 2010 at 5:46 PM, Dean Michael Berris
>> <mik...@gm...> wrote:
>> >
>> >  * The tags system now uses heavy metaprogramming with Boost.MPL.
>>
>
> Following on from another thread, all these changes from 0.6-0.7 need to be
> added to the docs, I think it means that what we have now is out-of-date.
>

Yes, definitely. I'm going to spend my day here bringing the docs up to date.

>>
>> PS. Please review the code and let me know if you find any glaring
>> bugs or really ugly things that need explanation. That would be
>> greatly appreciated. [1]
>
> I will make the time to do this.

Thanks Glyn, this would be greatly appreciated! :)

-- 
Dean Michael Berris
deanberris.com