Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!ucsd!ucbvax!DOCKMASTER.ARPA!Fitch From: Fitch@DOCKMASTER.ARPA Newsgroups: comp.protocols.tcp-ip Subject: Wollongong, Recvfrom, and UDP Message-ID: <880714153421.917343@DOCKMASTER.ARPA> Date: 14 Jul 88 15:34:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 55 I've had a few problems writing some UDP code under Wollongong's protocol suite for VMS. Now I think I know why. In the man-like documentation and in the QIO Programmer's Guide section of the Wollongong documentation, the recvfrom procedure takes a from parameter that is described as struct sockaddr_in *from that is the socket structure we all know and love. However, this does NOT get filled in correctly. I know the host I'm receiving from and the info returned in from is half right; i.e., two out of four IP address bytes are correct. It turns out that you need to pass a pointer to a structure like struct sock_from { unsigned short from_len; struct sockaddr_in from_dat; } The point is that from_len gives you two extra bytes which somehow makes a difference. Nevermind that the recvfrom call STILL needs a from_len parameter of its own. What I'm leaving out here is the only reason I discovered this is that after my Ada bombed (yes, there is a whole mess of pragmas and other stuff between me an the eventual QIO calls which is why it took me so long to track down the bug) I started taking a closer look at the Wollongong sample UDP code. I originally didn't pay too much attention to the example because it was written in MACRO (which I will confess/brag that I can read if I have to) and because the comments in the code were wrong (saying TCP instead of UDP, saying the server connected to the remote...). In the MACRO, the extra two bytes were passed in the recvfrom call (but note that these bytes are NOT required in the sendto call. The C examples used connected sockets and didn't need to spec the from parameter. However, if you look in the C include file, the sock_from type is defined, but it is never used in the examples. 1) To be polite, I will ask if I am just confused. 2) If the answer to 1 is NO, then WHY IS THIS SO? 3) The obvious impact is that UDP code or anything else that uses recvfrom will have to get modified to work on Wollongong. 4) I will probably try to funnel these questions to Wollongong through the sub-cons on our project that deal with them, but I would like some feedback if anyone else has written UDP code under Wollongong and if there is some reason all of this happens. Thanks. --Jack Fitch -at Dockmaster.arpa