home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / protocol / tcpip / 5096 < prev    next >
Encoding:
Internet Message Format  |  1992-11-09  |  3.0 KB
  1. Xref: sparky comp.protocols.tcp-ip:5096 comp.unix.wizards:4571
  2. Path: sparky!uunet!cs.utexas.edu!ut-emx!tivoli!paul
  3. From: paul@tivoli.UUCP (Paul Greenspan)
  4. Newsgroups: comp.protocols.tcp-ip,comp.unix.wizards
  5. Subject: TLI and non-blocking I/O
  6. Keywords: TLI, SVR4, non_blocking
  7. Message-ID: <5853@tivoli.UUCP>
  8. Date: 7 Nov 92 17:19:03 GMT
  9. Reply-To: paul@tivoli.com (Paul Greenspan)
  10. Followup-To: comp.protocols.tcp-ip
  11. Organization: TIVOLI Systems
  12. Lines: 63
  13.  
  14. Below is a description of a problem that we are having with some of
  15. our network code.  I would appreciate any help that I could get.  
  16.  
  17. Background:
  18. -----------
  19. We have taken a rather complicated server that was developed with BSD 
  20. sockets and converted it to use TLI.  The server has to handle many 
  21. things at once (with threads) so it is important that we use non-blocking 
  22. endpoints.  So to avoid blocking on a t_listen() call waiting 
  23. for a connection request, we wait for poll() to tell us that 
  24. there is a connection request and then try to call t_listen().
  25.  
  26. Here is a description of the behavior of some of our TLI code, as
  27. executed under SVR4.0.3:
  28.  
  29. [SERVER]
  30. 1. The server calls t_open(DEV_TCP, O_RDWR, 0).
  31. 2. The server calls ioctl(tfd, FIONBIO, &non_blocking) 
  32.    to set the TLI endpoint into non-blocking mode.
  33. 3. The server calls t_bind(tfd, &req, &ret) to offer 
  34.    a channel to clients. The bound address is selected 
  35.    by the transport provider (req.addr.len is 0) and 
  36.    gets recorded so clients can be told on what address 
  37.    to t_connect.
  38. 4. The server calls poll() to wait for connection requests.
  39.  
  40.             [CLIENT]
  41.             5. A client initiates a connection request by first 
  42.                calling t_open(DEV_TCP, O_RDWR, 0).
  43.             6. The client then calls t_bind(tfd, 0, 0)
  44.             7. The client calls t_connect(tfd, connreq, 0), where
  45.                connreq has been t_alloc'd, then set up with the 
  46.                correct address, no options, and no user data.
  47.  
  48.                NOTE: The client's t_connect will later appear to 
  49.                succeed. (Weird.)
  50.  
  51. [SERVER]
  52. 8. The server is notified of the connection request
  53.    by poll(). t_look(tfd) returns T_LISTEN (1).
  54. 9. The server calls t_listen(tfd, callptr), where 
  55.    callptr has been t_alloc'd but otherwise left alone. 
  56.    This call fails, returning -1. t_errno is 
  57.    TNOTSUPPORT (18).
  58.  
  59.             [CLIENT]
  60.             5.  A client initiates a connection request by first 
  61.                 calling t_open(DEV_TCP, O_RDWR, 0).
  62.             10. Here's the weird part. The client's t_connect 
  63.                 call now returns and indicates all is well. 
  64.                 So the client code keeps going.
  65.             11. The client calls ioctl(tfd, I_POP, 0)
  66.             12. The client calls ioctl(tfd, I_PUSH, "tirdwr")
  67.             13. The client calls write(tfd, buf, sizeof(u_long)).
  68.                 This succeeds!
  69.             14. The client calls read(tfd, buf, sizeof(u_long)). 
  70.                 This is where the client finally sees something 
  71.                 is wrong, as the read call returns 0.
  72.  
  73. -- 
  74. Paul Greenspan              paul@tivoli.com 
  75. Tivoli Systems              6034 West Courtyard, Suite 210
  76. Austin, Texas  78730        (512) 794-9070  /  FAX (512) 794-0623
  77.