home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / programm / 4516 < prev    next >
Encoding:
Text File  |  1992-09-02  |  2.2 KB  |  55 lines
  1. Newsgroups: comp.unix.programmer
  2. Path: sparky!uunet!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!fstop.csc.ti.com!pioneer!fcw
  3. From: fcw@telecom.ti.com (Fred Wedemeier)
  4. Subject: Re: Sending "datagrams" on a connected socket.
  5. Message-ID: <1992Sep2.182616.24007@csc.ti.com>
  6. Sender: usenet@csc.ti.com
  7. Nntp-Posting-Host: pioneer
  8. Reply-To: fcw@telecom.ti.com
  9. Organization: TI Telecom Systems, Dallas
  10. References: <1992Sep1.061951.6750@csc.ti.com>
  11. Date: Wed, 2 Sep 1992 18:26:16 GMT
  12. Lines: 41
  13.  
  14. In article 6750@csc.ti.com, fcw@telecom.ti.com (Fred Wedemeier) writes:
  15. > 
  16. > I need two processes to talk to each other in a "reliable,
  17. > flow-controlled, in-order, two-way" manner, quoting tcp(4). These
  18. > processes need to exchange discrete messages rather than boundary-less
  19. > streams of bytes.
  20. > 
  21.  
  22. and...
  23. > 
  24. > I can add a layer onto a stream or datagram socket, but it would be
  25. > nice if some incantation of socket library calls can do it instead.
  26.  
  27. Well, what I was hoping for was advice on some combination of socket(),
  28. bind(), or whatever that would allow me to do the above with a single
  29. send()/recv(), once the socket was created and bound properly. I guess I
  30. didn't ask the question clearly enough.
  31.  
  32. Many people were kind enough to reply with the almost unanimous
  33. suggestion to send() the byte count and then send() the text of the
  34. message.  On the receiving side, recv() the fixed-size byte count and
  35. then ask for that number of bytes in another recv(). Thx. for the
  36. responses!
  37.  
  38. In an application program, this would be sufficient since a connected
  39. socket guarantees sequential delivery of bytes. What I'm actually doing
  40. right now is building a comm API to be used by a group of programmers.
  41. The API needs to avoid the situation of an application program
  42. bypassing the API, communicating directly with the socket, and
  43. potentially getting the byte stream out of sync.
  44.  
  45. So the clarified question is "can I send/receive a 'datagram' on a
  46. connected socket with an atomic send()/recv()?" 
  47.  
  48. If the answer is no, I'll probably hide the descriptor or put a USER
  49. BEWARE in the API documentation.
  50.  
  51. ---
  52. Fred Wedemeier    pho: 214-997-3213     fax: 214-997-3639
  53.                 timsg: fcw             inet: fcw@pioneer.telecom.ti.com
  54.  
  55.