<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: sockets in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/sockets/m-p/2563824#M872771</link>
    <description>Hi:&lt;BR /&gt;&lt;BR /&gt;I suggest you look at the sendmsg() and recvmsg() system calls. These will come closest to doing what I think you are trying to do.</description>
    <pubDate>Thu, 09 Aug 2001 19:52:59 GMT</pubDate>
    <dc:creator>A. Clay Stephenson</dc:creator>
    <dc:date>2001-08-09T19:52:59Z</dc:date>
    <item>
      <title>sockets</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/sockets/m-p/2563821#M872768</link>
      <description>&lt;BR /&gt;When a TCP write is done on a socket, does the data get written to the TCP buffer in an atomic manner?&lt;BR /&gt;For eg. if 10K is written on the socket using a single write, can the receive call return less than 10K (say 8K in the first call and 2K in the nect call) ?&lt;BR /&gt;&lt;BR /&gt;Kapil</description>
      <pubDate>Thu, 09 Aug 2001 14:39:28 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/sockets/m-p/2563821#M872768</guid>
      <dc:creator>Kapil_2</dc:creator>
      <dc:date>2001-08-09T14:39:28Z</dc:date>
    </item>
    <item>
      <title>Re: sockets</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/sockets/m-p/2563822#M872769</link>
      <description>&lt;BR /&gt;When you read from a socket, you may specify the byte count to read.</description>
      <pubDate>Thu, 09 Aug 2001 16:04:32 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/sockets/m-p/2563822#M872769</guid>
      <dc:creator>harry d brown jr</dc:creator>
      <dc:date>2001-08-09T16:04:32Z</dc:date>
    </item>
    <item>
      <title>Re: sockets</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/sockets/m-p/2563823#M872770</link>
      <description>i'm not sure that "atomic" is the right term, but no, TCP does not do atomic writes as you describe - what we would otherwise call "preserving message boundaries"&lt;BR /&gt;&lt;BR /&gt;TCP is a byte-stream protocol. You feed it a stream of bytes (in whatever size chunks you choose) and a stream of bytes arrives at the other end. &lt;BR /&gt;&lt;BR /&gt;A send() of 10K of data may result in several 1460 byte recv()'s or some other value &amp;lt;= 10K.&lt;BR /&gt;&lt;BR /&gt;Your application has to be prepared to do things to preserve message boundaries. Typically, this is done by pre-pending a "header" with the total message size in it. &lt;BR /&gt;&lt;BR /&gt;I would suggest you write this "header" and the data to the socket at the same time - with say a call to writev() or sendmsg(). Do not do separate writes or you will encounter the nagle algorithm.&lt;BR /&gt;&lt;BR /&gt;the works of W. Richard Stevens would be very good to have handy if you are going to do any "network programming"</description>
      <pubDate>Thu, 09 Aug 2001 19:48:18 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/sockets/m-p/2563823#M872770</guid>
      <dc:creator>rick jones</dc:creator>
      <dc:date>2001-08-09T19:48:18Z</dc:date>
    </item>
    <item>
      <title>Re: sockets</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/sockets/m-p/2563824#M872771</link>
      <description>Hi:&lt;BR /&gt;&lt;BR /&gt;I suggest you look at the sendmsg() and recvmsg() system calls. These will come closest to doing what I think you are trying to do.</description>
      <pubDate>Thu, 09 Aug 2001 19:52:59 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/sockets/m-p/2563824#M872771</guid>
      <dc:creator>A. Clay Stephenson</dc:creator>
      <dc:date>2001-08-09T19:52:59Z</dc:date>
    </item>
    <item>
      <title>Re: sockets</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/sockets/m-p/2563825#M872772</link>
      <description>Hi Kapil:&lt;BR /&gt;&lt;BR /&gt;I'd add to Rick's comments.  In order to compose messages (records) from the byte stream arriving on your socket, and achieve some fidelity to what you pass to your application, I generally prepend a header and append a trailer.&lt;BR /&gt;&lt;BR /&gt;The header can include a character count (length inclusive string) which you then use to give a level of assurance that you received what you expected when you have found the trailer. &lt;BR /&gt;&lt;BR /&gt;As framing characters we use 'stx' for the header; and the pair 'fs' &amp;amp; 'cr' for the trailer.&lt;BR /&gt;&lt;BR /&gt;...JRF...</description>
      <pubDate>Thu, 09 Aug 2001 20:05:12 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/sockets/m-p/2563825#M872772</guid>
      <dc:creator>James R. Ferguson</dc:creator>
      <dc:date>2001-08-09T20:05:12Z</dc:date>
    </item>
    <item>
      <title>Re: sockets</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/sockets/m-p/2563826#M872773</link>
      <description>Rick,&lt;BR /&gt;That piece of information was helpful.&lt;BR /&gt;Was there a reason for mentioning 1460 or was it just a random figure you mentioned?&lt;BR /&gt;Also what is the Nagle Algorithm and when does it come into picture?&lt;BR /&gt;&lt;BR /&gt;Thanks to all of you for your replies.&lt;BR /&gt;&lt;BR /&gt;Kapil&lt;BR /&gt;</description>
      <pubDate>Tue, 14 Aug 2001 13:41:14 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/sockets/m-p/2563826#M872773</guid>
      <dc:creator>Kapil_2</dc:creator>
      <dc:date>2001-08-14T13:41:14Z</dc:date>
    </item>
    <item>
      <title>Re: sockets</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/sockets/m-p/2563827#M872774</link>
      <description>Hi Kapel:&lt;BR /&gt;&lt;BR /&gt;When short messages are transmitted with TCP/IP they are packed to avoid or reduce network congestion. The Nagle algorithm delays transmission of short messages to attempt to wait until more messages are available.&lt;BR /&gt;&lt;BR /&gt;...JRF...</description>
      <pubDate>Tue, 14 Aug 2001 14:45:42 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/sockets/m-p/2563827#M872774</guid>
      <dc:creator>James R. Ferguson</dc:creator>
      <dc:date>2001-08-14T14:45:42Z</dc:date>
    </item>
    <item>
      <title>Re: sockets</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/sockets/m-p/2563828#M872775</link>
      <description>1460 is commonly the MSS (maximum segment size) for TCP connections over links with 1500 byte MTUs.&lt;BR /&gt;&lt;BR /&gt;as for the rest - that is what Stevens' books are for !-) i suspect you could find boatloads of opinions on the nagle algorithm with a usenet search at groups.deja.com - some of them - the correct ones of course!-) would even be from me :)&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Thu, 23 Aug 2001 18:24:40 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/sockets/m-p/2563828#M872775</guid>
      <dc:creator>rick jones</dc:creator>
      <dc:date>2001-08-23T18:24:40Z</dc:date>
    </item>
  </channel>
</rss>

