Re: Why no socket package in the standard ?

["Yannick Duchêne (Hibou57)" <yannick_duchene@yahoo.fr>]

Le Tue, 24 May 2011 12:00:24 +0200, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:
> 1. The reason simply is that each and every of them has started
> by offering some glue code for the BSD/POSIX socket functions.
BSD is the standard C API for sockets, even the POSIX one, intially based  
on the BSD specification, was kept close enough. The POSIX specification  
seems to only differs in the way to get host by name / address.

> .NET languages will likely just use a .NET class.
Which is probably a tick binding to the socket API (if I'm wrong with  
this, tell me).

> But there have been and will be difficulties when porting
> the languages' alleged "standard" libraries to non-POSIX
> (or non-.NET) operating systems.  Perhaps the difficulties
> are even conceptual ones whenever POSIX sockets don't really
> meet the networking requirements.
What networking requirement ? This thread is not about OSI layers packages  
for Ada, it's only about sockets, which is either OSI layer 4 or 5  
(depending on the point of view).

> Define
>
>   Commercially_Important_Platforms := {
>     ∃ target | POSIX(target) IN { False, True }
>   }
>
> How large is the subset defined by POSIX(target) = False?
> Is POSIX/Sockets the best Ada solution when this is the case?
Be pragmatic : the standard socket API is the BSD socket API, then as said  
above, there are only little differences between the POSIX and BSD socket  
specification, and then after, sockets does not implies POSIX. POSIX is  
one thing, sockets is another.


> 2. In the light of Ada's history regarding standardization,
> there is, I believe, networking knowledge that warrants more
> than canonization of a practical workaround---which might fail
> if requirements are actually different.
What workaround ?

> Opposing a get-that-duct-tape-solution-out–the-door style for
> standardization, I'd imagine starting from questions like the
> following and then weigh POSIX sockets as the possible answer:
Why not, POSIX would be OK, indeed, as it provides the same. But there  
should be good reason to introduce POSIX here. This would be OK if there  
was support for POSIX in the Ada standard, and this is actually not.

> - What should programs be able to do when communicating data
>   along some network connection?
Answered by the socket specification : there are raw, datagram, stream,  
blocking and none-blocking sockets, with IPv4 or IPv6 addresses.

> - Should there be a layered approach?  How much detail?
Sockets already belong to its layer, but Ada is not concerned about it.  
This is not about creating a network package hierarchy, this is about a  
socket package only (may be a hierarchy, if it appears to be cleaner this  
way).

> - Where in the language will this integrate nicely?
>   (E.g. package structure? What types if any?  Or anything
>   that has already been mentioned.)
Streams in some part, but not always, has some usage of sockets does not  
have stream behavior (like UDP). This would probably requires two sockets  
type : streams and none-stream.

> - Is sockets the right approach?  Consider Erlang!
Seems Erlang actually provides sockets.

> - Is sockets the right approach?  Consider a CAN!
A can 8-) ?

> I doubt that the best answer to these questions can
> be summed up by saying, "Mirror Posix sockets!".
Why ? Thousands of applications are working nice with either POSIX or BSD  
sockets, and this was not cause of any big troubles I could hear about,  
unlike stack or buffer overflow, lack of typing and the like. Sockets are  
a mostly secure things. And Ada has tasking defined in the language, which  
can be useful for sockets (think about the "select" operation, while not  
formally required, is often used in conjunction with sockets).


> [*]  
> http://pike.ida.liu.se/generated/manual/modref/ex/predef_3A_3A/Stdio/Port.html
>
> [**] http://www.snobol4.org/csnobol4/curr/doc/snobol4.html
>
> [***] "Haskell's networking functions almost always correspond
> directly to familiar C function calls."
> http://book.realworldhaskell.org/read/sockets-and-syslog.html
OK, will get some time to read these.


-- 
Si les chats miaulent et font autant de vocalises bizarres, c’est pas pour  
les chiens.
“ c++; /* this makes c bigger but returns the old value */ ” [Anonymous]