Newbie: Could use tutorial guidance of experienced TCP/IP sockets programmer

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.**--****.com/ 

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;
}

> using namespace std; // For time_t, time and ctime;
>> time_t now = time(0);>
> return ctime(&now)>
> >
> int main(>
> >
> t>y
> > {
> boost::asio::io_service io_ser>ic>;
>
> tcp::acceptor acceptor(io_service, tcp::endpoint(tcp::v4()> 1>));
>
> gt;for (;>)
> {
> tcp::socket socke>(io_service);
> accepto>.a>cept(socket);
>
> std::string message = ma>e_>aytime_string();
>
> boost::system::er>or_code ignored_error;
> boost::asio::write(socket, boo>t::asio::buffer(message),
> boost::asio::>ransfe>_all(>, ignored_error);
> }
>>}
> {
><gt;std>:c>rr << e.what(> <> std>:e>dl;
> }
>
> 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.**--****.com/ 

> > using namespace std; // For time_t, time and ctime;
>>>> time_t now = time(0);>
> > return ctime(&now)>
>
>> > int main(>
>> > >
>> > t>y>
> > > >
> > boost::asio::io_service io_ser>ic>;>
>
> > tcp::acceptor acceptor(io_service, tcp::endpoint(tcp::v4()> 1>)>;
>
> > gt;f>r (;;)>
> > {
> > tcp::socket socke>(>o_service);
> > accepto>.a>c>pt(socket);
>
> > std::string message = ma>e_>a>time_string();
>
> > boost::system::er>o>_code ignored_error;
> > boost::asio::write(socket, boo>t>:asio::buffer(message),
> > boost::asio::>r>nsfer_>l>(), i>n>red_error);
> > }
> > gt;}>
> > > >atch (std::exception& e)
> > lt;{
> > g<<gt;std::>er> >< e.what() <<>st>:>endl>
>
> > return 0;
>
> > }
>
> Please don't tell me go and >ead the Stevens books. I have them, but
> they are>in>a different continent right now. :-)
>
> All I need is > l>ttle nu>ge>in the ri>ht>direction...
>
> TIA,
>
> -Ramon
>
>  http://www.**--****.com/ 


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

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:  XXXX@XXXXX.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

> SIEMENS Power Transmission & Distribution hone: gt;952) 607-2244
> Energy Management & Automation Division ax: > 952) 607-2018
> 10900 Wayzata Bou>evard, 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

 > Try a 'using namespace boost::asio' here.
 > I don't mind a bit of C++ namespace qualification,
 > but three or four levels of colons in your
 > code are just too much for me.

Your request is being referred to Christopher M. Kohlhoff, the author
of Boosto.Asio. :-)

 http://www.**--****.com/ 

I copied and pasted that program. Chose the simplest of the 7
provided. I assume he used that style for didactic reasons.

-Ramon

>  IP as an encrypted equivalent: IPsec
>>  TCP has an encrypted equivalent: SSL>
>>
> but there is no such thing as an encrypted UDP.

DTLS can thought of as an encrypted UDP.
 http://www.**--****.com/ 

There are, to some extent, good reasons why encrypted datagram
protocols aren't popular. Part of it is that most of the advantages of
datagram protocols are hard to replicate in a secure protocol. For
example, designing a secure broadcast protocol is non-trivial, and
would require some other channel to negotiate the keys. Also, unless
you implement your own retransmissions and acknowledgements, keeping
the encryption context the same on both ends becomes challenging.

DS

<snip>

> The read_some operation may not read all of the req>ested
> number>of>bytes.
>
> This being a property your [] library share> with the
> underlying system call. TCP does not preserve message bounda>ies which
> implies that, if you need to read 'messages', you mus> design a
> protocol such that the end of a message can be rec>gnized by
> inspecting the data recevied so far and continue to call >ead until
> such an end of message indication was seen.

Note "end of message indication" could be a count at the beginning of
the message. Otherwise you have to do "byte-stuffing" or such like to
avoid false positives on EOM detection.