Fitch@DOCKMASTER.ARPA (07/14/88)
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.arpajerry@TWG.COM (Jerry Scott) (07/15/88)
You are obviously using the QIO interface to the Wollongong software rather than the SOCKET interface. The SOCKET interface takes care of the extra two bytes. Since those wishing to port code to VMS using the Wollongong software usually start with code using the SOCKET interface, no modifications are necessary. Don't know who is porting networking code written in Ada using QIO's. If people are doing that then yes some modification will be necessary. Jerry
mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) (07/15/88)
Don't understand why you're proud that you can read MACRO when you have to! MACRO is wonderfully explicit unlike C which lacks clarity and Ada which is totally obscure.
cire@CLASH.CISCO.COM (07/15/88)
>> Date: Thu, 14 Jul 88 13:49:24 PDT >> From: mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) >> To: Fitch@DOCKMASTER.ARPA, tcp-ip@SRI-NIC.ARPA >> Subject: Re: Wollongong, Recvfrom, and UDP >> >> Don't understand why you're proud that you can read MACRO when you have to! >> MACRO is wonderfully explicit unlike C which lacks clarity and Ada which is >> totally obscure. Let's not get religious here. Sure MACRO is explicit but that is different than clarity. MACRO is clear when you understand it. I think this is generally true for any language (computer that is). To someone that doesn't know the machine the MACRO is for a program will be very obscure. But that isn't true for the higher level languages. That is once you understand the language. -c cire|eric Eric B. Decker cisco Systems Menlo Park, California email: cire@cisco.com uSnail: 1360 Willow Rd., Menlo Park, CA 94025 Phone : (415) 326-1941
sms@ETN-WLV.EATON.COM (Steven M. Schultz) (07/15/88)
>Don't understand why you're proud that you can read MACRO when you have to! >MACRO is wonderfully explicit unlike C which lacks clarity and Ada which is >totally obscure. and in a pinch even the rudimentary assembler that's provided with Unix systems is a pleasant switch. ummm, C is perfectly clear, don't mistake unfamiliarity with lack of clarity - please. Ada is a language designed by a committee which brings to mind the old Alan Sherman quote: "a camel is a horse designed by a committee". Steven M. Schultz sms@etn-wlv.eaton.com