Page 1 of 2

Rolling my own linux networking code..

Posted: Thu Dec 30, 2004 10:34 am
by SurreaL
Hello everyone. I finally got around to getting the proper libraries and such installed on my debian box, to be able to start tinkering with network programming using PB, within Linux. I have been pleasantly surprised that there are certain API calls which I would require which seem to be recognized already by PB (most notably, socket_, and fcntl_.. enough to set up a non-blocking socket) So things were looking good.. so far.

Then after some further research, I noticed that the unfortunate downside is that certain constants required by these commands seem to be not defined. (Whereas the similar ones are, over in Windows PB land) I have gone to some lengths to find out which constants I will require, and have been able to find out where they have been declared in the libraries included with debian. The part where I am having a problem however, is after noting the following excerpt from '/usr/include/sys/socket.h' which states:
/* This operating system-specific header file defines the SOCK_*, PF_*,
AF_*, MSG_*, SOL_*, and SO_* constants, and the `struct sockaddr',
`struct msghdr', and `struct linger' types. */
#include [bits/socket.h] (angle brackets replaced by square brackets so as to not be parsed as html..)
Now after going through and looking at '/usr/include/bits/socket.h', I see SOCK_DGRAM being declared as "2". (I am only really looking at UDP because I am thinking of writing a cross-platform UDP library..)

This is all fine and good, because I can just write my own constant definitions to use from my PB lib in calling the linux networking API functions, including this required constant as well as several others.. however the confusion begins when I cross-reference this with some online searching I had done (a la trusty Google) I had found this page: http://www.cs.ucl.ac.uk/staff/S.Bhatti/ ... c-sockets/

If you scroll down about half way through the page, it shows that whatever OS this is has an include <sys/socket.h>, which defines SOCK_DGRAM as being 1! (And SOCK_STREAM is 2.. ie the exact opposite of what I am seeing here on my debian box!)

This now obviously causes me some distress, as I am unable at least to my knowledge to include or process C header files in PB, and as such I have no way of knowing what proper value to pass to the API calls (such as socket_, etc) And me being such a newbie to linux.. I thought it best that perhaps I try to confirm these findings with my fellow linux pb'ers :) (Hey if this gets sorted there could be a good networking lib in it for ya, hehe!)

Basically I just wanted to know if anybody else out there could check and see what the constants SOCK_DGRAM and SOCK_STREAM are defined on your system.. They should be defined somewhere around <sys/socket.h>, although if they are not there (as in my case), there should be another include mentioned in socket.h which will show you where to look.

Thanks in advance for any help :)

Posted: Thu Dec 30, 2004 11:04 am
by olejr
On my Mandrake 10.1 these defines are in bits/socket.h, and this file is included in /sys/socket.h..
Anyway.. SOCK_DGRAM = 2 & SOCK_STREAM = 1

You could also take a look here http://www.opengroup.org/onlinepubs/007908799/

Posted: Thu Dec 30, 2004 5:06 pm
by SurreaL
Hm ok so that's two flavours out of many which I can count on the constants being the same.. thanks for your input!

how about any redhat users out there? I believe the link I pasted mentioned having some code which worked on redhat and solaris and some other OS's..perhaps I can hear from one of those users in the crowd?

Posted: Thu Dec 30, 2004 5:54 pm
by olejr
It's me again :wink:
Fedora Core 1 is the same as Mandrake..
And this do cover for, I think, every RPM based distro...

Another thing I noticed when following your link is that
they have SOCK_RAW defined as 4.. On both my systems it is 3..

If you do a google on #define SOCK_STREAM you find that most,
if not all is defined as 1..

I also found this:
Note that i386 and mips swapped the values
for SOCK_STREAM and SOCK_DGRAM.
So I'd say that your link is for MIPS programming...

Posted: Thu Dec 30, 2004 7:56 pm
by SurreaL
well.. Further experimentation has once again gotten my hopes up only to be inevitably stuck at a more crucial point :/

It seems that the function sendto_ (one which is somewhat mandatory for doing UDP programming) isn't expecting the amount of variables it should be..

both the guide I've been following here: http://www.ecst.csuchico.edu/~beej/guid ... sendtorecv

along with the actual man pages for sendto on my debian system, are both indicating that sendto should have 6 parameters. But for some reason trying to compile my sockets code fails on the following line:

Code: Select all

sendto_ (sock, @msg, len(msg), 0, @destaddr, sizeof(sockaddr_in))
stating that "Line 45: sendto() : Incorrect number of of parameters."

It seems it is expecting 5 parameters, as if I remove one of them (at random..) then the code compiles, but the function call naturally fails (since it indeed is looking for one more parameter I imagine..)

Anyways.. this is proving to be pretty disheartening at best :/ I think I may be better off choosing another language for my purposes.. (Maybe I'm better off to just crack down and learn C better)

Posted: Thu Dec 30, 2004 8:45 pm
by olejr
Take a look at the sources here: http://pont.net/socket/
Maybe it helps abit.. Question.. You're doing it in PB??

Posted: Thu Dec 30, 2004 9:14 pm
by SurreaL
yeah.. that link just confirms what all the other sources have shown me, ie sendto takes 6 parameters.. not the 5 that PB is expecting.

And yes, I *was* going to try to do it in PB.. but it seems this has effectively put an end to that, heh. I suppose now I might look into writing dll's for linux..

Posted: Thu Dec 30, 2004 9:46 pm
by olejr
I've opened the purelibraries/linux/glibc in a hex editor, and yes the sendto accept only 5 parameters.. This is a 'bug', but if you change the 5 to a 6 it seems to work...

And for the dll...??? You are talking about .so right?:wink: here's a link to get you started..
http://users.actcom.co.il/~choo/lupg/tu ... aries.html

PS I've been thinking about the UPDNetwork library myself, but time/kids (reallife) hasn't been on my "programming" side.. And then along came this new thing called b-max so.. But I'll get around to it eventually.. If someone doesn't do it earlier...

Posted: Fri Dec 31, 2004 12:09 am
by SurreaL
ah.. hey that's pretty cool :) um.. how did you do that again? hehe.. I guess I'll have to find a hex editor and see if I can figure out something like that on me own!

Posted: Fri Dec 31, 2004 12:29 am
by olejr
I use Windows & UltraEdit for such things.. Don't know a good (read any) HEX editor in Linux....

I'm of to bug reporting.. :roll:

Posted: Fri Dec 31, 2004 12:39 am
by SurreaL
well.. I did some searching around and installed the deb package for hexedit. I then managed to hexedit the file (after being sure to back it up) I was able to figure out how to use it and took a look at the libraries file you mentioned.. anyhow, I found the function declaration, and I will assume I found the proper value to edit two bytes afterwards (which was set to 5)

Ok so I've set it to 6, and now it compiles, it just seems that the sendto_ function isn't working the way it should :/ but I'm going to look into it further.. thanks for your help so far :)

Posted: Fri Dec 31, 2004 12:54 am
by olejr
Hmmm.... Did you remove the backup from the purelibraries folder??
If not, maybe that's the problem.. PB load everything it find in there you know...

EDIT: Never mind.. missed your last post... & Good luck :wink:

Posted: Fri Dec 31, 2004 1:23 am
by SurreaL
thanks!

progress is being made.. albeit slowly but surely, hehe

Posted: Fri Dec 31, 2004 1:46 am
by olejr
Maybe the HEX edit didn't do the trick anyway...
Because now there's a sudden stop in the program when it comes to the sento_ .... Doesn't print/do anything after that... :roll:
Maybe you should wait for an answer in the bugforum..

Posted: Fri Dec 31, 2004 7:21 am
by SurreaL
yeah I dunno.. I'm getting some funky results from the code so I'm probably going to have to drop it for now..