Differences in interpretation of native PB network code.

Everything else that doesn't fall into one of the other PB categories.
User avatar
skywalk
Addict
Addict
Posts: 4003
Joined: Wed Dec 23, 2009 10:14 pm
Location: Boston, MA

Re: Fred, I believe you are mistaken on this...

Post by skywalk »

Hi Rich,
Please change the title of your thread to something more meaningful to the community. Addressing Fred or anyone else personally is better handled with private messages. :wink:
Thanks for posting bugs/suggestions that will improve the language for all of us.
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
User avatar
RichAlgeni
Addict
Addict
Posts: 914
Joined: Wed Sep 22, 2010 1:50 am
Location: Bradenton, FL

Re: Differences in interpretation of native PB network code.

Post by RichAlgeni »

Understood Skywalk. Consider me slapped.

How's this?
User avatar
skywalk
Addict
Addict
Posts: 4003
Joined: Wed Dec 23, 2009 10:14 pm
Location: Boston, MA

Re: Differences in interpretation of native PB network code.

Post by skywalk »

Thanks...thread has more meaning now 8)
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
auser
Enthusiast
Enthusiast
Posts: 195
Joined: Wed Sep 06, 2006 6:59 am

Re: Fred, I believe you are mistaken on this...

Post by auser »

BorisTheOld wrote: Zero seems perfectly normal to me, since in most languages zero means false, and anything else means true.

Returning -1 to mean false is what's confusing, but unfortunately that's the way PB works.
I don't agree. It's the normal behaviour of berkely socket programming (windows, linux, ...). If somebody start network programming with OS functions himself following are very basic ones:


socket():
> -1 = File descriptor
-1 = Invalid socket

listen():
0 = Everything ok
-1 = A socket error occured (e.g. socket already connected)

bind():
0 = Everything ok
-1 = A socket error occured (e.g. port is already in use)

accept():
> -1 = File descriptor
-1 = A socket error occured (e.g. too many open fds)

select()
> 1 = One or more sockets from your array are able to read or write or whatever you told select to check for you
0 = No socket was ready to read or write or whatever you've checked
-1 = A socket error occured (which could be many different like "connection unexpected closed" or "please try again" on non-blocking stuff)

recv()
> 1 = num of bytes that was read successfully
0 = client gracefully disconnected
-1 = A socket error occured (which could mean yet again something serious or something non-fatal)

send()
> -1 = num of bytes sent
-1 = A socket error occured (which could mean send again or connection reset by peer or whatever)


Conclusion: You could get "-1" very often at socket programming. The current PB Network functions are just not made for the purpose of "check just one socket in one thread". If you need that behaviour I would recommend use the berkeley socket commands. So you could "accept" one after each other in your main and do the work seperated in your client threads without the need to sort out all incoming events again in your mainthread for sockets you already forwarded to one of your threads. Afterwards you have the freedom to check just one socket by one select or switch to nonblocking or change different timeout values or handle mutlicasts and so on. PB network functions are good if you would use them in just one thread (either main or not). Unfortunately the current "OpenWindows()" implemention forces you to use that (imho) "non-modular" behaviour everywhere else. And while it's easy to workaround at network programming (coz the berkeley functions are used almost the same on different OS) it's a pain at windows() programming.


Greetings,
auser
BorisTheOld
Enthusiast
Enthusiast
Posts: 542
Joined: Tue Apr 24, 2012 5:08 pm
Location: Ontario, Canada

Re: Differences in interpretation of native PB network code.

Post by BorisTheOld »

In that case, -1 would seem to be perfectly reasonable. :)
For ten years Caesar ruled with an iron hand, then with a wooden foot, and finally with a piece of string.
~ Spike Milligan
Post Reply