Standardizing Sockets

Standard Sockets Library for smalltalk.

dCSSS, Draft Camp Smalltalk Sockets Standard

Participants: Janko Mivsek, Reinout Heeck, Mark Schwenk, Alex Pikovsky, Peter Hatch, Paolo Bonzini, Craig Latta.

Related projects: Internet client/server framework, Smalltalk Web Services, Smalltalk Web Application Server.

• Here is a draft, please scribble on it: Draft Camp Smalltalk Sockets Standard.
• Discussion about dCSSS method names
• dCSSS meetings
• Socket Standard Workshop at Smalltalk Solutions 2001, Results of Socket Standard Workshop at SS2001
• CS3

Sockets Documentation:

• Protocols
• IP
• www.protocols.com/pbook/tcpip.htm
• SMB/Windows;
• SAMBA Developer resources
• www.protocols.com/pbook/ibm.htm netbios&smb
• DDP/AppleTalk
• netatalk
• www.protocols.com/pbook/appletalk.htm

• APIs
• The GNU C library reference manual.
• man(4) atalk
• Protocol Independence Problems and the Berkely API.
  'many programs assume that a ``port'' is an integer'
• rfc3493 Basic Socket Interface Extensions for IPv6.
• rfc3542 Advanced Sockets API for IPv6. (for ping, traceroute, routing daemons etc.)

• Smalltalk Sockets Implementations
• Sockets/V by P1 (for single threaded Smalltalks?)
• TCP/IP in GNU Smalltalk
• GUSI on VW
• Flow

• We should define at least:
  - basic socket interface
  - streaming over sockets
  Also, we should be pragmatic and define only common socket functions, and avoid more advanced ones (like out of bound data etc.). --JM
• I strongly disagree, we should cover all types of sockets with all their functionality. We should define a mechanism that allows implementations to be partial, and a way for the development environment (not neccasarily the app) to discover what is implemented.
  -I once wrote a VNC client in VW and I was very glad that there was access to the 'socket options'.
  -I once tried to write a telnet proxy/screenscraper and I was very disappointed that OOB messaging did not work. --RH
  --(However, the reason OOB messaging didn't/doesn't work is because VW uses non-blocking IO on sockets and doesn't provide access to detecting _only_ "exceptional events" with the select(2) or poll(2) syscalls. Passable OOB messaging support would exist if #setSem:forWrite: was rewritten as #setSem:forCondition: where the second argument is one of CONDITION_WRITE, CONDITION_READ, or CONDITION_EXCEPTION. The message could be multiplexed if the "condition" argument was the bitwise OR of the three possible condition argument values. Peter Hatch)

• One idea I had about tackling this matter was defining a standard expression of the Berkeley Sockets library that is available on all platforms, and implement that (eg. using DLLCC in VW). On top of that define layers (streams would be the first) that look more like Smalltalk, and are pretty much the same (implementationwise!) for all platforms. Note that if we do it along such a path we don't absolutely need vendor's participation up front. --RH

• The implementation of TCP/IP in GNU Smalltalk is quite good in my opinion. The code looks very much like you are using standard Streams, like Reinout suggests above; it is also complete, since the development snapshot (which is linked above) has out of band data and raw sockets. The only non-portable part is the implementation of marshaling/unmarshaling, which relies on GNU Smalltalk's own BOSS-like layer; this could be replaced by SOAP however. I have already ported WikiWorks to run on it.--Paolo Bonzini

• I suggest that the sockets standard will define only one global name. All other sockets objects are referenced from there. Suggested names: 'CSSocketFactory', 'CSSockets', 'Sockets'. --RH

• I started a draft 'standard document' so we have something to scribble on: Draft Camp Smalltalk Sockets Standard. --RH