From: Ramon F Herrera on

Hello all,

I have been programming under U*ix for ages, but this is the first
time I have gathered the courage to attempt dealing with such scary
black art as sockets. :^)

As an introductory, tutorial-type material, these programs are great
(see simplest one below):

http://www.boost.org/doc/libs/1_40_0/doc/html/boost_asio/tutorial.html

I am trying to take the 'daytime' code for client and server and adapt
them to my needs.

My main problem is that such code was designed to transfer a short
string from the server to the client. Using my own data, the client
and server handle properly a few lines being transferred, but as soon
as the data is more than a handful lines, some data is lost.

Note: The transfer (request) from the client is short -just a few
parameters- but the server may return about 1K bytes.

It seems that the client is being overwhelmed by the server's
response. Reading at the docs I am guessing that the limitation is
caused by something called "short read".

Perhaps I need a larger buffer or something.

Conceptual info is most appreciated...

Thanks for your kind assistance,

-Ramon


-----------------------------

#include <ctime>
#include <iostream>
#include <string>
#include <boost/asio.hpp>

using boost::asio::ip::tcp;

std::string make_daytime_string()
{
using namespace std; // For time_t, time and ctime;
time_t now = time(0);
return ctime(&now);
}

int main()
{
try
{
boost::asio::io_service io_service;

tcp::acceptor acceptor(io_service, tcp::endpoint(tcp::v4(), 13));

for (;;)
{
tcp::socket socket(io_service);
acceptor.accept(socket);

std::string message = make_daytime_string();

boost::system::error_code ignored_error;
boost::asio::write(socket, boost::asio::buffer(message),
boost::asio::transfer_all(), ignored_error);
}
}
catch (std::exception& e)
{
std::cerr << e.what() << std::endl;
}

return 0;
}

From: Ramon F Herrera on
On Sep 11, 11:32 am, Ramon F Herrera <ra...(a)conexus.net> wrote:
> Hello all,
>
> I have been programming under U*ix for ages, but this is the first
> time I have gathered the courage to attempt dealing with such scary
> black art as sockets. :^)
>
> As an introductory, tutorial-type material, these programs are great
> (see simplest one below):
>
> http://www.boost.org/doc/libs/1_40_0/doc/html/boost_asio/tutorial.html
>
> I am trying to take the 'daytime' code for client and server and adapt
> them to my needs.
>
> My main problem is that such code was designed to transfer a short
> string from the server to the client. Using my own data, the client
> and server handle properly a few lines being transferred, but as soon
> as the data is more than a handful lines, some data is lost.
>
> Note: The transfer (request) from the client is short -just a few
> parameters- but the server may return about 1K bytes.
>
> It seems that the client is being overwhelmed by the server's
> response. Reading at the docs I am guessing that the limitation is
> caused by something called "short read".
>
> Perhaps I need a larger buffer or something.
>
> Conceptual info is most appreciated...
>
> Thanks for your kind assistance,
>
> -Ramon
>
> -----------------------------
>
> #include <ctime>
> #include <iostream>
> #include <string>
> #include <boost/asio.hpp>
>
> using boost::asio::ip::tcp;
>
> std::string make_daytime_string()
> {
>   using namespace std; // For time_t, time and ctime;
>   time_t now = time(0);
>   return ctime(&now);
>
> }
>
> int main()
> {
>   try
>   {
>     boost::asio::io_service io_service;
>
>     tcp::acceptor acceptor(io_service, tcp::endpoint(tcp::v4(), 13));
>
>     for (;;)
>     {
>       tcp::socket socket(io_service);
>       acceptor.accept(socket);
>
>       std::string message = make_daytime_string();
>
>       boost::system::error_code ignored_error;
>       boost::asio::write(socket, boost::asio::buffer(message),
>           boost::asio::transfer_all(), ignored_error);
>     }
>   }
>   catch (std::exception& e)
>   {
>     std::cerr << e.what() << std::endl;
>   }
>
>   return 0;
>
> }
>
>

Please don't tell me go and read the Stevens books. I have them, but
they are in a different continent right now. :-)

All I need is a little nudge in the right direction...

TIA,

-Ramon

http://www.amazon.com/TCP-IP-Illustrated-1-Protocols/dp/0201633469

From: Ramon F Herrera on
On Sep 11, 11:42 am, Ramon F Herrera <ra...(a)conexus.net> wrote:
> On Sep 11, 11:32 am, Ramon F Herrera <ra...(a)conexus.net> wrote:
>
>
>
> > Hello all,
>
> > I have been programming under U*ix for ages, but this is the first
> > time I have gathered the courage to attempt dealing with such scary
> > black art as sockets. :^)
>
> > As an introductory, tutorial-type material, these programs are great
> > (see simplest one below):
>
> >http://www.boost.org/doc/libs/1_40_0/doc/html/boost_asio/tutorial.html
>
> > I am trying to take the 'daytime' code for client and server and adapt
> > them to my needs.
>
> > My main problem is that such code was designed to transfer a short
> > string from the server to the client. Using my own data, the client
> > and server handle properly a few lines being transferred, but as soon
> > as the data is more than a handful lines, some data is lost.
>
> > Note: The transfer (request) from the client is short -just a few
> > parameters- but the server may return about 1K bytes.
>
> > It seems that the client is being overwhelmed by the server's
> > response. Reading at the docs I am guessing that the limitation is
> > caused by something called "short read".
>
> > Perhaps I need a larger buffer or something.
>
> > Conceptual info is most appreciated...
>
> > Thanks for your kind assistance,
>
> > -Ramon
>
> > -----------------------------
>
> > #include <ctime>
> > #include <iostream>
> > #include <string>
> > #include <boost/asio.hpp>
>
> > using boost::asio::ip::tcp;
>
> > std::string make_daytime_string()
> > {
> >   using namespace std; // For time_t, time and ctime;
> >   time_t now = time(0);
> >   return ctime(&now);
>
> > }
>
> > int main()
> > {
> >   try
> >   {
> >     boost::asio::io_service io_service;
>
> >     tcp::acceptor acceptor(io_service, tcp::endpoint(tcp::v4(), 13));
>
> >     for (;;)
> >     {
> >       tcp::socket socket(io_service);
> >       acceptor.accept(socket);
>
> >       std::string message = make_daytime_string();
>
> >       boost::system::error_code ignored_error;
> >       boost::asio::write(socket, boost::asio::buffer(message),
> >           boost::asio::transfer_all(), ignored_error);
> >     }
> >   }
> >   catch (std::exception& e)
> >   {
> >     std::cerr << e.what() << std::endl;
> >   }
>
> >   return 0;
>
> > }
>
> Please don't tell me go and read the Stevens books. I have them, but
> they are in a different continent right now. :-)
>
> All I need is a little nudge in the right direction...
>
> TIA,
>
> -Ramon
>
> http://www.amazon.com/TCP-IP-Illustrated-1-Protocols/dp/0201633469


More questions:

In my preliminary client & server versions, I will send the data in
clear text, but a future version will be based on SSL.

Given that future direction (SSL on Version 2), should I base my
Version 1 on:

(1) UDP
(2) TCP
(3) Irrelevant

-Ramon

From: Tom Einertson on
"Ramon F Herrera" <ramon(a)conexus.net> wrote in message
news:2670b840-9d5d-4f7b-9683-45d96a82ece2(a)o9g2000yqj.googlegroups.com...
> In my preliminary client & server versions, I will send the data in
> clear text, but a future version will be based on SSL.
>
> Given that future direction (SSL on Version 2), should I base my
> Version 1 on:
>
> (1) UDP
> (2) TCP
> (3) Irrelevant

If you plan to convert to SSL eventually, then I would use TCP for Version
1. Although there are
differences between TCP and SSL (SSL is more complicated) both of these
protocols provide the
same type of service (stream). UDP provides a datagram service, so you
have to deal with a
different set of issues.

--
Tom Einertson E-mail: tom.einertson(a)siemens.com
SIEMENS Power Transmission & Distribution Phone: (952) 607-2244
Energy Management & Automation Division Fax: (952) 607-2018
10900 Wayzata Boulevard, Suite 400
Minnetonka, MN, 55305


From: Ramon F Herrera on
On Sep 11, 1:25 pm, "Tom Einertson" <t...(a)siemens-emis.com> wrote:
> "Ramon F Herrera" <ra...(a)conexus.net> wrote in messagenews:2670b840-9d5d-4f7b-9683-45d96a82ece2(a)o9g2000yqj.googlegroups.com...
>
> > In my preliminary client & server versions, I will send the data in
> > clear text, but a future version will be based on SSL.
>
> > Given that future direction (SSL on Version 2), should I base my
> > Version 1 on:
>
> > (1) UDP
> > (2) TCP
> > (3) Irrelevant
>
> If you plan to convert to SSL eventually, then I would use TCP for Version
> 1.  Although there are
> differences between TCP and SSL (SSL is more complicated) both of these
> protocols provide the
> same type of service (stream).   UDP provides a datagram service, so you
> have to deal with a
> different set of issues.
>
> --
> Tom Einertson                              E-mail: tom.einert...(a)siemens.com
> SIEMENS Power Transmission & Distribution  Phone:  (952) 607-2244
> Energy Management & Automation Division    Fax:    (952) 607-2018
> 10900 Wayzata Boulevard, Suite 400
> Minnetonka, MN, 55305


Thanks, Tom. You confirmed my suspicions. I have always wondered why:

- IP has an encrypted equivalent: IPsec
- TCP has an encrypted equivalent: SSL

but there is no such thing as an encrypted UDP.

Regards,

-Ramon