totty@m.cs.uiuc.edu (10/07/88)
I have some questions about sockets that maybe I can get answers to... 1) Is there a book that describes sockets? The Sun man pages I have are not enough. 2) Using a connected stream will send block until it is able to send all of its data? I have a program where send will return but only having sent some of the data. The length field returns the # of bytes sent, but I thought send returned only when all data had been sent... 3) When I close a socket, the select() call on the other end thinks it is ready to be read. Is this what is supposed to happen? How does the other end know when the remote socket closed the connection? Is there an end-of-file status? Thanks, --- Bri / Brian Totty o o /__ __ o URH 655 Sherman / 909 S. Fifth o / / / / Champaign, IL 61820 \_/ "We have corn in /__/ / / totty@a.cs.uiuc.edu Massachusetts too!"
mike@turing.unm.edu (Michael I. Bushnell) (10/10/88)
In article <9000010@m.cs.uiuc.edu> totty@m.cs.uiuc.edu writes: > I have some questions about sockets that maybe I > can get answers to... I'll try... > 1) Is there a book that describes sockets? The Sun > man pages I have are not enough. 4.3 BSD comes with the documents: An Introductory 4.3BSD Interprocess Communication Tutorial Advanced 4.3BSD IPC Tutorial You could probably find something similar in your Sun manual set. > 2) Using a connected stream will send block until > it is able to send all of its data? I have a > program where send will return but only having > sent some of the data. The length field returns > the # of bytes sent, but I thought send returned > only when all data had been sent... You should check the return value of write() to see how much data has actually been sent. There is no guarantee that the full amount will be sent. > 3) When I close a socket, the select() call on the > other end thinks it is ready to be read. Is > this what is supposed to happen? How does the > other end know when the remote socket closed > the connection? Is there an end-of-file status? Select() is actually telling you that it can be read without blocking. If you actually go ahead and read it, you will read 0 bytes, which indicates EOF. N u m q u a m G l o r i a D e o \ Michael I. Bushnell \ HASA - "A" division /\ mike@turing.unm.edu / \ {ucbvax,gatech}!unmvax!turing.unm.edu!mike
brister@td2cad.intel.com (James Brister) (10/09/89)
Hi,
I have a couple of questions regarding sockets on Ultrix 3.x.
1) I have a process that listens to a socket, when a connection request comes
in the process forks and the child takes care of the connection while the
parent goes back to listening for more connections. I've seen code do this
under the INET address family, but not under AF_UNIX and I was wondering... I
haven't seen this stated in the doc set, but is it guaranteed that if two child
process from the same parent are handling two connections at the same time that
the connections are really seperate (i.e. reads/writes to one won't get crossed
with the other). I'm about 95% certain this is safe (isn't this what lpd
does?), but the overloading of the (socket) filename bothers me. Does this
also work with AF_UNIX (guaranteed?). I've run some test cases and it looks
good, but I don't want to use something that may someday blow up in my face.
2) Is there some way for a process to wait for connections on more than one
socket and then handle the first one that comes through? (something along the
lines of select) Or am I stuck using multiple processes?
Thanks.
James
--
James Brister brister@td2cad.intel.com
Intel Corp. {decwrl,oliveb}!td2cad!brister