Initial SCTP support for the upcoming 1.6.5 release

Initial SCTP support for the upcoming 1.6.5 release

[Michael Tuexen]

[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]

Dear all,

it would be very helpful for me (and some others) if the 1.6.5 release
could have some support for SCTP.

To see what kind of change this requires I'm appending the diff files
for libguile/socket.[ch].

What are the changes (for socket.h)?

- add to prototypes for sctp-recvmsg and sctp-sendmsg.
   These changes are #ifdefed.

What are the changes (for socket.c)?

- include <netinet/sctp.h> if available. #ifdefed.
- add two line of code to initialize socket structures to zero.
   (If you do not like these two changes, take them out. They helped
    for some SCTP implementations not doing this in the kernel. At
    least one of them is fixed now).
- add sctp-recvmsg and sctp-sendmsg wrapper functions. These are 
#ifdefed.
- add some constants, if they are available. #ifdefed.

What is still missing (configure.in)?

- A check for the existence of netinet/sctp.h. If yes, define 
HAVE_NETINET_SCTP_H
- A check if sctp_sendmsg is contained in libsctp. If yes, define 
HAVE_SCTP_SENDMSG
   an add libsctp to the list of libraries to be used.
- A check if sctp_recvmsg is contained in libsctp. If yes, define 
HAVE_SCTP_RECVMSG
   an add libsctp to the list of libraries to be used.

(libsctp is located on some platforms in /usr/lib, /usr/local/lib and 
/usr/local/v6/lib)
This can be done by adding some lines to configure.in.

I will test the configure.in changes and send a patch for configure.in 
later
this week.

Please let me know if these patches can be included in the upcoming 
1.6.5 release.

Thank you very much.

Best regards
Michael


[-- Attachment #2: socket.c.diff --]
[-- Type: application/octet-stream, Size: 7735 bytes --]

--- guile-core-20040808/libguile/socket.c	Fri Mar 15 10:23:19 2002
+++ guile-core-mod/libguile/socket.c	Tue Aug 10 20:23:56 2004
@@ -71,6 +71,9 @@
 #include <netinet/in.h>
 #include <netdb.h>
 #include <arpa/inet.h>
+#ifdef HAVE_NETINET_SCTP_H
+#include <netinet/sctp.h>
+#endif
 #endif
 
 #if defined (HAVE_UNIX_DOMAIN_SOCKETS) && !defined (SUN_LEN)
@@ -706,6 +709,7 @@
 	  scm_memory_error (proc);
 	/* 4.4BSD-style interface includes sin_len member and defines SIN_LEN,
 	   4.3BSD  does not.  */
+	memset((void *)soka, 0, sizeof(struct sockaddr_in));
 #ifdef SIN_LEN
 	soka->sin_len = sizeof (struct sockaddr_in);
 #endif
@@ -742,6 +746,7 @@
 	soka = (struct sockaddr_in6 *) malloc (sizeof (struct sockaddr_in6));
 	if (!soka)
 	  scm_memory_error (proc);
+	memset((void *)soka, 0, sizeof(struct sockaddr_in6));
 #ifdef SIN_LEN6
 	soka->sin6_len = sizeof (struct sockaddr_in6);
 #endif
@@ -1202,6 +1207,72 @@
 }
 #undef FUNC_NAME
 
+#ifdef HAVE_SCTP_RECVMSG
+
+SCM_DEFINE (scm_sctp_recvmsg, "sctp-recvmsg!", 2, 2, 0,
+            (SCM sock, SCM str, SCM start, SCM end),
+	    "Return data from the socket port @var{sock} and also\n"
+	    "information about where the data was received from.\n"
+	    "@var{sock} must already be bound to the address from which\n"
+	    "data is to be received.  @code{str}, is a string into which the\n"
+	    "data will be written.  The size of @var{str} limits the amount\n"
+	    "of data which can be received: in the case of packet protocols,\n"
+	    "if a packet larger than this limit is encountered then some\n"
+	    "data will be irrevocably lost.\n\n"
+	    "The value returned is a list containing:\n"
+	    "- the number of bytes read from the socket\n"
+	    "- an address object in the same form as returned by @code{accept}\n"
+	    "- the flags returned by the sctp_recvmsg call\n"
+	    "- a list containing the SID, SSN, PPID, TSN and CUM_TSN\n"
+	    "The @var{start} and @var{end} arguments specify a substring of\n"
+	    "@var{str} to which the data should be written.\n\n"
+	    "Note that the data is read directly from the socket file\n"
+	    "descriptor: any unread buffered port data is ignored.")
+#define FUNC_NAME s_scm_sctp_recvmsg
+{
+  int rv;
+  int fd;
+  int flg;
+  char *buf;
+  int offset;
+  int cend;
+  SCM address, s_sinfo;
+  int addr_size = MAX_ADDR_SIZE;
+  char max_addr[MAX_ADDR_SIZE];
+  struct sockaddr *addr = (struct sockaddr *) max_addr;
+  struct sctp_sndrcvinfo sinfo;
+  
+  SCM_VALIDATE_OPFPORT (1, sock);
+  fd = SCM_FPORT_FDES (sock);
+  SCM_VALIDATE_SUBSTRING_SPEC_COPY (2, str, buf, 3, start, offset,
+				    4, end, cend);
+
+  addr->sa_family = AF_UNSPEC;
+  flg = 0;
+  SCM_SYSCALL (rv = sctp_recvmsg (fd, buf + offset,
+			          cend - offset,
+			          addr, &addr_size,
+			          &sinfo,
+			          &flg));
+  if (rv == -1)
+    SCM_SYSERROR;
+  if (addr->sa_family != AF_UNSPEC)
+    address = scm_addr_vector (addr, FUNC_NAME);
+  else
+    address = SCM_BOOL_F;
+
+  s_sinfo = scm_list_5(scm_ushort2num(sinfo.sinfo_stream),
+                       scm_ushort2num(sinfo.sinfo_ssn),
+                       scm_uint2num(ntohl(sinfo.sinfo_ppid)),
+                       scm_uint2num(sinfo.sinfo_tsn),
+                       scm_uint2num(sinfo.sinfo_cumtsn));
+                       
+  return scm_list_4 (SCM_MAKINUM (rv), address, SCM_MAKINUM (flg), s_sinfo); 
+}
+#undef FUNC_NAME
+
+#endif
+
 SCM_DEFINE (scm_sendto, "sendto", 4, 0, 1,
             (SCM sock, SCM message, SCM fam, SCM address, SCM args_and_flags),
 	    "Transmit the string @var{message} on the socket port\n"
@@ -1257,7 +1328,70 @@
   return SCM_MAKINUM (rv);
 }
 #undef FUNC_NAME
-\f
+
+#ifdef HAVE_SCTP_SENDMSG
+\fSCM_DEFINE (scm_sctp_sendmsg, "sctp-sendmsg", 8, 0, 1,
+            (SCM sock, SCM message, SCM ppid, SCM stream_no, SCM ttl, SCM context, SCM fam, SCM address, SCM args_and_flags),
+	    "Transmit the string @var{message} on the socket port\n"
+	    "@var{sock}.  The\n"
+	    "parameters @var{ppid}, @var{stream_no}, @var{ttl} and  @var{context}\n"
+	    "are the corresponding SCTP parameters. The\n"
+	    "destination address is specified using the @var{fam},\n"
+	    "@var{address} and\n"
+	    "@var{args_and_flags} arguments, in a similar way to the\n"
+	    "@code{connect} procedure.  @var{args_and_flags} contains\n"
+	    "the usual connection arguments optionally followed by\n"
+	    "a flags argument, which is a value or\n"
+	    "bitwise OR of MSG_UNORDERED, MSG_ABORT, MSG_EOF etc.\n\n"
+	    "The value returned is the number of bytes transmitted\n"
+	    "Note that the data is written directly to the socket\n"
+	    "file descriptor:\n"
+	    "any unflushed buffered port data is ignored.")
+#define FUNC_NAME s_scm_sctp_sendmsg
+{
+  int rv;
+  int fd;
+  int flg;
+  struct sockaddr *soka;
+  int size;
+  uint16_t c_stream_no;
+  uint32_t c_ppid, c_ttl, c_context;
+
+  sock = SCM_COERCE_OUTPORT (sock);
+  SCM_VALIDATE_FPORT (1, sock);
+  SCM_VALIDATE_STRING (2, message);
+  c_ppid      = htonl(SCM_NUM2ULONG(3, ppid));
+  c_stream_no = SCM_NUM2USHORT(4, stream_no);
+  c_ttl       = SCM_NUM2ULONG(5, ttl);
+  c_context   = SCM_NUM2ULONG(6, context);
+  SCM_VALIDATE_INUM (7, fam);
+  fd = SCM_FPORT_FDES (sock);
+  soka = scm_fill_sockaddr (SCM_INUM (fam), address, &args_and_flags, 8, FUNC_NAME, &size);
+  if (SCM_NULLP (args_and_flags))
+    flg = 0;
+  else {
+      SCM_VALIDATE_CONS (9,args_and_flags);
+      flg = SCM_NUM2ULONG (9, SCM_CAR (args_and_flags));
+    }
+
+  SCM_SYSCALL (rv = sctp_sendmsg (fd,  SCM_STRING_CHARS (message), SCM_STRING_LENGTH (message),
+			          soka, size,
+				  c_ppid,
+				  flg,
+				  c_stream_no,
+				  c_ttl,
+				  c_context));
+  if (rv == -1) {
+      int save_errno = errno;
+      free (soka);
+      errno = save_errno;
+      SCM_SYSERROR;
+  }
+  free (soka);
+  return SCM_MAKINUM (rv);
+}
+#undef FUNC_NAME
+\f#endif
 
 
 void
@@ -1311,10 +1445,26 @@
 #ifdef SOCK_DGRAM
   scm_c_define ("SOCK_DGRAM", SCM_MAKINUM (SOCK_DGRAM));
 #endif
+#ifdef SOCK_SEQPACKET
+  scm_c_define ("SOCK_SEQPACKET", SCM_MAKINUM (SOCK_SEQPACKET));
+#endif
 #ifdef SOCK_RAW
   scm_c_define ("SOCK_RAW", SCM_MAKINUM (SOCK_RAW));
 #endif
 
+  /* protocol numbers */
+#ifdef IPPROTO_SCTP
+  scm_c_define ("IPPROTO_SCTP", SCM_MAKINUM (IPPROTO_SCTP));
+#endif
+
+#ifdef IPPROTO_TCP
+  scm_c_define ("IPPROTO_TCP", SCM_MAKINUM (IPPROTO_TCP));
+#endif
+
+#ifdef IPPROTO_UDP
+  scm_c_define ("IPPROTO_UDP", SCM_MAKINUM (IPPROTO_UDP));
+#endif
+
   /* setsockopt level.  */
 #ifdef SOL_SOCKET
   scm_c_define ("SOL_SOCKET", SCM_MAKINUM (SOL_SOCKET));
@@ -1382,6 +1532,30 @@
 #endif
 #ifdef MSG_DONTROUTE
   scm_c_define ("MSG_DONTROUTE", SCM_MAKINUM (MSG_DONTROUTE));
+#endif
+#ifdef MSG_UNORDERED
+  scm_c_define ("MSG_UNORDERED", SCM_MAKINUM (MSG_UNORDERED));
+#endif
+#ifdef MSG_ADDR_OVER
+  scm_c_define ("MSG_ADDR_OVER", SCM_MAKINUM (MSG_ADDR_OVER));
+#endif
+#ifdef MSG_ABORT
+  scm_c_define("MSG_ABORT", SCM_MAKINUM (MSG_ABORT));
+#endif
+#ifdef MSG_EOF
+  scm_c_define ("MSG_EOF", SCM_MAKINUM (MSG_EOF));
+#endif
+#ifdef MSG_EOR
+  scm_c_define ("MSG_EOR", SCM_MAKINUM (MSG_EOR));
+#endif
+#ifdef MSG_NOTIFICATION
+  scm_c_define ("MSG_NOTIFICATION", SCM_MAKINUM (MSG_NOTIFICATION));
+#endif
+#ifdef MSG_PR_SCTP_TTL
+  scm_c_define ("MSG_PR_SCTP_TTL", SCM_MAKINUM (MSG_PR_SCTP_TTL));
+#endif
+#ifdef MSG_PR_SCTP_BUF
+  scm_c_define ("MSG_PR_SCTP_BUF", SCM_MAKINUM (MSG_PR_SCTP_BUF));
 #endif
 
   scm_add_feature ("socket");

[-- Attachment #3: socket.h.diff --]
[-- Type: application/octet-stream, Size: 819 bytes --]

--- guile-core-20040808/libguile/socket.h	Sun Apr 22 18:05:21 2001
+++ guile-core-mod/libguile/socket.h	Tue Aug 10 19:28:49 2004
@@ -74,7 +74,13 @@
 extern SCM scm_recv (SCM sockfd, SCM buff_or_size, SCM flags);
 extern SCM scm_send (SCM sockfd, SCM message, SCM flags);
 extern SCM scm_recvfrom (SCM sockfd, SCM buff_or_size, SCM flags, SCM offset, SCM length);
+#ifdef HAVE_SCTP_RECVMSG
+extern SCM scm_sctp_recvmsg (SCM sockfd, SCM buff_or_size, SCM offset, SCM length);
+#endif
 extern SCM scm_sendto (SCM sockfd, SCM message, SCM fam, SCM address, SCM args_and_flags);
+#ifdef HAVE_SCTP_SENDMSG
+extern SCM scm_sctp_sendmsg (SCM sockfd, SCM message, SCM ppid, SCM stream_no, SCM ttl, SCM context, SCM fam, SCM address, SCM args_and_flags);
+#endif
 extern void scm_init_socket (void);
 
 #endif  /* SCM_SOCKETH */

[-- Attachment #4: Type: text/plain, Size: 1 bytes --]



[-- Attachment #5: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Initial SCTP support for the upcoming 1.6.5 release

[Michael Tuexen]

[-- Attachment #1: Type: text/plain, Size: 458 bytes --]

Dear all,

I have now a complete list of changes (attached as diff files).

I also changed the handling in socket.[ch]: Instead of using
HAVE_SCTP_RECVMSG and HAVE_SCTP_SENDMSG I'm only using
HAVE_SCTPLIB.

I checked Linux, FreeBSD and Solaris and all have both functions
defined in libsctp.

Please let me know if it is possible to include these changes in
the 1.6.5 release.

Best regards
Michael

PS.: The changes have been tested on FC2 Linux and BSD.



[-- Attachment #2: configure.in.diff --]
[-- Type: application/octet-stream, Size: 610 bytes --]

203c203
< AC_CHECK_HEADERS([assert.h io.h libc.h limits.h malloc.h memory.h string.h regex.h rxposix.h rx/rxposix.h sys/ioctl.h sys/select.h sys/time.h sys/timeb.h sys/times.h sys/stdtypes.h sys/types.h sys/utime.h time.h unistd.h utime.h pwd.h winsock2.h grp.h sys/utsname.h netinet/sctp.h])
---
> AC_CHECK_HEADERS([assert.h io.h libc.h limits.h malloc.h memory.h string.h regex.h rxposix.h rx/rxposix.h sys/ioctl.h sys/select.h sys/time.h sys/timeb.h sys/times.h sys/stdtypes.h sys/types.h sys/utime.h time.h unistd.h utime.h pwd.h winsock2.h grp.h sys/utsname.h])
219d218
< AC_CHECK_LIB(sctp, sctp_sendmsg)

[-- Attachment #3: socket.c.diff --]
[-- Type: application/octet-stream, Size: 6475 bytes --]

74,76d73
< #ifdef HAVE_NETINET_SCTP_H
< #include <netinet/sctp.h>
< #endif
712d708
< 	memset((void *)soka, 0, sizeof(struct sockaddr_in));
749d744
< 	memset((void *)soka, 0, sizeof(struct sockaddr_in6));
1210,1275d1204
< #ifdef HAVE_LIBSCTP
< 
< SCM_DEFINE (scm_sctp_recvmsg, "sctp-recvmsg!", 2, 2, 0,
<             (SCM sock, SCM str, SCM start, SCM end),
< 	    "Return data from the socket port @var{sock} and also\n"
< 	    "information about where the data was received from.\n"
< 	    "@var{sock} must already be bound to the address from which\n"
< 	    "data is to be received.  @code{str}, is a string into which the\n"
< 	    "data will be written.  The size of @var{str} limits the amount\n"
< 	    "of data which can be received: in the case of packet protocols,\n"
< 	    "if a packet larger than this limit is encountered then some\n"
< 	    "data will be irrevocably lost.\n\n"
< 	    "The value returned is a list containing:\n"
< 	    "- the number of bytes read from the socket\n"
< 	    "- an address object in the same form as returned by @code{accept}\n"
< 	    "- the flags returned by the sctp_recvmsg call\n"
< 	    "- a list containing the SID, SSN, PPID, TSN and CUM_TSN\n"
< 	    "The @var{start} and @var{end} arguments specify a substring of\n"
< 	    "@var{str} to which the data should be written.\n\n"
< 	    "Note that the data is read directly from the socket file\n"
< 	    "descriptor: any unread buffered port data is ignored.")
< #define FUNC_NAME s_scm_sctp_recvmsg
< {
<   int rv;
<   int fd;
<   int flg;
<   char *buf;
<   int offset;
<   int cend;
<   SCM address, s_sinfo;
<   int addr_size = MAX_ADDR_SIZE;
<   char max_addr[MAX_ADDR_SIZE];
<   struct sockaddr *addr = (struct sockaddr *) max_addr;
<   struct sctp_sndrcvinfo sinfo;
<   
<   SCM_VALIDATE_OPFPORT (1, sock);
<   fd = SCM_FPORT_FDES (sock);
<   SCM_VALIDATE_SUBSTRING_SPEC_COPY (2, str, buf, 3, start, offset,
< 				    4, end, cend);
< 
<   addr->sa_family = AF_UNSPEC;
<   flg = 0;
<   SCM_SYSCALL (rv = sctp_recvmsg (fd, buf + offset,
< 			          cend - offset,
< 			          addr, &addr_size,
< 			          &sinfo,
< 			          &flg));
<   if (rv == -1)
<     SCM_SYSERROR;
<   if (addr->sa_family != AF_UNSPEC)
<     address = scm_addr_vector (addr, FUNC_NAME);
<   else
<     address = SCM_BOOL_F;
< 
<   s_sinfo = scm_list_5(scm_ushort2num(sinfo.sinfo_stream),
<                        scm_ushort2num(sinfo.sinfo_ssn),
<                        scm_uint2num(ntohl(sinfo.sinfo_ppid)),
<                        scm_uint2num(sinfo.sinfo_tsn),
<                        scm_uint2num(sinfo.sinfo_cumtsn));
<                        
<   return scm_list_4 (SCM_MAKINUM (rv), address, SCM_MAKINUM (flg), s_sinfo); 
< }
< #undef FUNC_NAME
< 
< #endif
< 
1331,1394c1260
< 
< #ifdef HAVE_LIBSCTP
< \fSCM_DEFINE (scm_sctp_sendmsg, "sctp-sendmsg", 8, 0, 1,
<             (SCM sock, SCM message, SCM ppid, SCM stream_no, SCM ttl, SCM context, SCM fam, SCM address, SCM args_and_flags),
< 	    "Transmit the string @var{message} on the socket port\n"
< 	    "@var{sock}.  The\n"
< 	    "parameters @var{ppid}, @var{stream_no}, @var{ttl} and  @var{context}\n"
< 	    "are the corresponding SCTP parameters. The\n"
< 	    "destination address is specified using the @var{fam},\n"
< 	    "@var{address} and\n"
< 	    "@var{args_and_flags} arguments, in a similar way to the\n"
< 	    "@code{connect} procedure.  @var{args_and_flags} contains\n"
< 	    "the usual connection arguments optionally followed by\n"
< 	    "a flags argument, which is a value or\n"
< 	    "bitwise OR of MSG_UNORDERED, MSG_ABORT, MSG_EOF etc.\n\n"
< 	    "The value returned is the number of bytes transmitted\n"
< 	    "Note that the data is written directly to the socket\n"
< 	    "file descriptor:\n"
< 	    "any unflushed buffered port data is ignored.")
< #define FUNC_NAME s_scm_sctp_sendmsg
< {
<   int rv;
<   int fd;
<   int flg;
<   struct sockaddr *soka;
<   int size;
<   uint16_t c_stream_no;
<   uint32_t c_ppid, c_ttl, c_context;
< 
<   sock = SCM_COERCE_OUTPORT (sock);
<   SCM_VALIDATE_FPORT (1, sock);
<   SCM_VALIDATE_STRING (2, message);
<   c_ppid      = htonl(SCM_NUM2ULONG(3, ppid));
<   c_stream_no = SCM_NUM2USHORT(4, stream_no);
<   c_ttl       = SCM_NUM2ULONG(5, ttl);
<   c_context   = SCM_NUM2ULONG(6, context);
<   SCM_VALIDATE_INUM (7, fam);
<   fd = SCM_FPORT_FDES (sock);
<   soka = scm_fill_sockaddr (SCM_INUM (fam), address, &args_and_flags, 8, FUNC_NAME, &size);
<   if (SCM_NULLP (args_and_flags))
<     flg = 0;
<   else {
<       SCM_VALIDATE_CONS (9,args_and_flags);
<       flg = SCM_NUM2ULONG (9, SCM_CAR (args_and_flags));
<     }
< 
<   SCM_SYSCALL (rv = sctp_sendmsg (fd,  SCM_STRING_CHARS (message), SCM_STRING_LENGTH (message),
< 			          soka, size,
< 				  c_ppid,
< 				  flg,
< 				  c_stream_no,
< 				  c_ttl,
< 				  c_context));
<   if (rv == -1) {
<       int save_errno = errno;
<       free (soka);
<       errno = save_errno;
<       SCM_SYSERROR;
<   }
<   free (soka);
<   return SCM_MAKINUM (rv);
< }
< #undef FUNC_NAME
< \f#endif
---
> \f
1448,1450d1313
< #ifdef SOCK_SEQPACKET
<   scm_c_define ("SOCK_SEQPACKET", SCM_MAKINUM (SOCK_SEQPACKET));
< #endif
1455,1467d1317
<   /* protocol numbers */
< #ifdef IPPROTO_SCTP
<   scm_c_define ("IPPROTO_SCTP", SCM_MAKINUM (IPPROTO_SCTP));
< #endif
< 
< #ifdef IPPROTO_TCP
<   scm_c_define ("IPPROTO_TCP", SCM_MAKINUM (IPPROTO_TCP));
< #endif
< 
< #ifdef IPPROTO_UDP
<   scm_c_define ("IPPROTO_UDP", SCM_MAKINUM (IPPROTO_UDP));
< #endif
< 
1535,1558d1384
< #endif
< #ifdef MSG_UNORDERED
<   scm_c_define ("MSG_UNORDERED", SCM_MAKINUM (MSG_UNORDERED));
< #endif
< #ifdef MSG_ADDR_OVER
<   scm_c_define ("MSG_ADDR_OVER", SCM_MAKINUM (MSG_ADDR_OVER));
< #endif
< #ifdef MSG_ABORT
<   scm_c_define("MSG_ABORT", SCM_MAKINUM (MSG_ABORT));
< #endif
< #ifdef MSG_EOF
<   scm_c_define ("MSG_EOF", SCM_MAKINUM (MSG_EOF));
< #endif
< #ifdef MSG_EOR
<   scm_c_define ("MSG_EOR", SCM_MAKINUM (MSG_EOR));
< #endif
< #ifdef MSG_NOTIFICATION
<   scm_c_define ("MSG_NOTIFICATION", SCM_MAKINUM (MSG_NOTIFICATION));
< #endif
< #ifdef MSG_PR_SCTP_TTL
<   scm_c_define ("MSG_PR_SCTP_TTL", SCM_MAKINUM (MSG_PR_SCTP_TTL));
< #endif
< #ifdef MSG_PR_SCTP_BUF
<   scm_c_define ("MSG_PR_SCTP_BUF", SCM_MAKINUM (MSG_PR_SCTP_BUF));

[-- Attachment #4: socket.h.diff --]
[-- Type: application/octet-stream, Size: 312 bytes --]

77,79d76
< #ifdef HAVE_LIBSCTP
< extern SCM scm_sctp_recvmsg (SCM sockfd, SCM buff_or_size, SCM offset, SCM length);
< #endif
81,83d77
< #ifdef HAVE_LIBSCTP
< extern SCM scm_sctp_sendmsg (SCM sockfd, SCM message, SCM ppid, SCM stream_no, SCM ttl, SCM context, SCM fam, SCM address, SCM args_and_flags);
< #endif

[-- Attachment #5: Type: text/plain, Size: 1884 bytes --]


On Aug 10, 2004, at 8:26 PM, Michael Tuexen wrote:

> Dear all,
>
> it would be very helpful for me (and some others) if the 1.6.5 release
> could have some support for SCTP.
>
> To see what kind of change this requires I'm appending the diff files
> for libguile/socket.[ch].
>
> What are the changes (for socket.h)?
>
> - add to prototypes for sctp-recvmsg and sctp-sendmsg.
>   These changes are #ifdefed.
>
> What are the changes (for socket.c)?
>
> - include <netinet/sctp.h> if available. #ifdefed.
> - add two line of code to initialize socket structures to zero.
>   (If you do not like these two changes, take them out. They helped
>    for some SCTP implementations not doing this in the kernel. At
>    least one of them is fixed now).
> - add sctp-recvmsg and sctp-sendmsg wrapper functions. These are 
> #ifdefed.
> - add some constants, if they are available. #ifdefed.
>
> What is still missing (configure.in)?
>
> - A check for the existence of netinet/sctp.h. If yes, define 
> HAVE_NETINET_SCTP_H
> - A check if sctp_sendmsg is contained in libsctp. If yes, define 
> HAVE_SCTP_SENDMSG
>   an add libsctp to the list of libraries to be used.
> - A check if sctp_recvmsg is contained in libsctp. If yes, define 
> HAVE_SCTP_RECVMSG
>   an add libsctp to the list of libraries to be used.
>
> (libsctp is located on some platforms in /usr/lib, /usr/local/lib and 
> /usr/local/v6/lib)
> This can be done by adding some lines to configure.in.
>
> I will test the configure.in changes and send a patch for configure.in 
> later
> this week.
>
> Please let me know if these patches can be included in the upcoming 
> 1.6.5 release.
>
> Thank you very much.
>
> Best regards
> Michael
>
> <socket.c.diff><socket.h.diff>
> _______________________________________________
> Guile-devel mailing list
> Guile-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/guile-devel

[-- Attachment #6: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Initial SCTP support for the upcoming 1.6.5 release

[Marius Vollmer]

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:

> Please let me know if it is possible to include these changes in
> the 1.6.5 release.

Hi Michael,

we don't want to include this in Guile 1.6.5.  The reason is that the
SCTP functions are not 'core' functionality and they can take not
advantage of being in the core.  Also, it would add another dependency
to Guile (on libsctp).

As long as SCTP needs an external library and is not supported
directly by libc, we think it is better to not include it in
guile-core.

I have turned your patch into a complete package that installs
libguile-net-sctp.so and the module (net sctp), you just need to fill
in the README, etc.  Scheme code can access the new module with

    (use-modules (net sctp))

Unfortunately, I couldn't test it since I don't seem to have sctp
support on my box.

Here:

    http://www-dt.e-technik.uni-dortmund.de/~mvo/guile-sctp-0.0.tar.gz


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Initial SCTP support for the upcoming 1.6.5 release

[Michael Tuexen]

Marius,

see my comments below.

Best regards
Michael

On Aug 13, 2004, at 3:40 PM, Marius Vollmer wrote:

> Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:
>
>> Please let me know if it is possible to include these changes in
>> the 1.6.5 release.
>
> Hi Michael,
>
> we don't want to include this in Guile 1.6.5.  The reason is that the
> SCTP functions are not 'core' functionality and they can take not
> advantage of being in the core.  Also, it would add another dependency
> to Guile (on libsctp).
>
OK, that is your decision.
> As long as SCTP needs an external library and is not supported
> directly by libc, we think it is better to not include it in
> guile-core.
Hmm. This might be a bit special. The functions socket, send, recv
and so on are simply extended to support SCTP. New functions will
not become part of libc. All SCTP implementations (well, the
Linux Kernel implementation, the BSD kernel implementation and
the Solaris implementation) provide the sctp_* functions in a
libsctp library. This is similar to Solaris, for example, where
you need to link against a socket library to use socket functions.
So they is also not part of libc. But, yes, networking is not core
functionality, it is only needed by some, not by all, programs.
>
> I have turned your patch into a complete package that installs
> libguile-net-sctp.so and the module (net sctp), you just need to fill
> in the README, etc.  Scheme code can access the new module with
>
>     (use-modules (net sctp))
>
> Unfortunately, I couldn't test it since I don't seem to have sctp
> support on my box.
If you have a recent 2.6 kernel, there should be sctp... possibly
as a module.

I'll test the module and let you know if it works. Are these modules
separately distributed or as part of guile 1.6.5?

Since I'm using guile as a framework for SCTP and SIGTRAN test tools
I need some way of distributing the SCTP enhanced version of guile.
So if it is included it is the simplest way for me, I can just say
'install guile 1.6.5'. If it is distributed separately, I can just
say 'install guile 1.6.5 and install a module from ...'. Both ways
are fine with me. I just do not want to distribute a modified version
of guile on my own...
>
> Here:
>
>     http://www-dt.e-technik.uni-dortmund.de/~mvo/guile-sctp-0.0.tar.gz
>
Thank you for your effort, I will let you know if it works.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Initial SCTP support for the upcoming 1.6.5 release

[Marius Vollmer]

>> As long as SCTP needs an external library and is not supported
>> directly by libc, we think it is better to not include it in
>> guile-core.
>
> Hmm. This might be a bit special. The functions socket, send, recv
> and so on are simply extended to support SCTP. New functions will
> not become part of libc. All SCTP implementations (well, the
> Linux Kernel implementation, the BSD kernel implementation and
> the Solaris implementation) provide the sctp_* functions in a
> libsctp library. This is similar to Solaris, for example, where
> you need to link against a socket library to use socket functions.
> So they is also not part of libc. But, yes, networking is not core
> functionality, it is only needed by some, not by all, programs.

I think I have misunderstood the nature of SCTP.  Although one can
argue that networking is not needed by all programs, we nevertheless
do provide sockets in guile-core.  So, from the perspective of Guile,
networking clearly is core functionality, right now.

I thought SCTP was a kind of additional protocol for a specific
purpose, like maybe FTP or HTTP.  I don't think we should have support
for protocols like this in guile-core.  (I did understand that SCTP is
on the same layer as TCP and UDP...)

But as you say, SCTP seems different.  The socket function directly
understands the request for SOCK_SEQPACKET (which will use SCTP,
right?) and you can use the read/write syscalls to use such a socket.

Is that correct?


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Initial SCTP support for the upcoming 1.6.5 release

[Michael Tuexen]

Marius,

see my comments in-line.

Best regards
Michael

On Aug 24, 2004, at 4:15 PM, Marius Vollmer wrote:

>
>>> As long as SCTP needs an external library and is not supported
>>> directly by libc, we think it is better to not include it in
>>> guile-core.
>>
>> Hmm. This might be a bit special. The functions socket, send, recv
>> and so on are simply extended to support SCTP. New functions will
>> not become part of libc. All SCTP implementations (well, the
>> Linux Kernel implementation, the BSD kernel implementation and
>> the Solaris implementation) provide the sctp_* functions in a
>> libsctp library. This is similar to Solaris, for example, where
>> you need to link against a socket library to use socket functions.
>> So they is also not part of libc. But, yes, networking is not core
>> functionality, it is only needed by some, not by all, programs.
>
> I think I have misunderstood the nature of SCTP.  Although one can
> argue that networking is not needed by all programs, we nevertheless
> do provide sockets in guile-core.  So, from the perspective of Guile,
> networking clearly is core functionality, right now.
>
That is correct and on some platforms (Solaris, for example) you
have to link against some additional libraries.
> I thought SCTP was a kind of additional protocol for a specific
> purpose, like maybe FTP or HTTP.  I don't think we should have support
> for protocols like this in guile-core.  (I did understand that SCTP is
> on the same layer as TCP and UDP...)
Possibly I was not clear enough. Yes, SCTP is at the same layer as TCP
or UDP, it is implemented in the kernel and accessible via the normal
socket API. You can used all socket function with SCTP after getting
the socket via
s = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)
(in this case it can be used similar to TCP)
or
s = socket(AF_INET, SOCK_SEQPACKET, IPPROTO_SCTP)
(in which case it can be used similar to UDP)
Since SCTP support some additional features compared to TCP and UDP
not everything could be mapped in an appropriate way to the
existing API, such that we defined some new functions, named sctp_*
(sctp_connectx, sctp_bindx, ...). These are normally available
in a special library depending on the system (some define these
functions using special sysctl, some define by using other general
socket API functions).
>
> But as you say, SCTP seems different.  The socket function directly
> understands the request for SOCK_SEQPACKET (which will use SCTP,
> right?) and you can use the read/write syscalls to use such a socket.
Yes you are right. You can port (some) application running over
TCP to SCTP by just replacing
s = socket(AF_INET, SOCK_STREAM, 0)
by
s = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP)
or a UDP based application from
s = socket(AF_INET, SOCK_DGRAM, 0)
by
s = socket(AF_INET, SOCK_SEQPACKET, IPPROTO_SCTP)

SCTP is a transport layer which is used for transporting telephony
signalling (SS7) over IP. It will also be used in other areas, but
I have developed test tools (a tool which is used to test SS7/IP
and SCTP implementations). The tests are implemented in scheme
and guile is extended to support SCTP. These tests will be published
(as open source) soon, and I found guile to be a very good tool
for this application. To have an easy way for people using these
test tools I need an defined procedure to get an SCTP enabled guile
on different hosts (Linux, BSD, Solaris, Mac OS X). I got the
solution as an extension now working but it would be simpler
(from the user perspective or the code perspective) to
have the SCTP functions included in socket.c.
The two functions I need are the send/receive functions which
allow to access an additional SCTP protocol element, which describes
the upper layer. That is why I can not use the provided send/receive
functions. sendmsg and recvmsg would work with extensive use of
CMG_HDRs, but guile does not provide an API for these functions
(and providing them is not that simple, because they use very
generic stuff).
>
> Is that correct?
Yes. I hope it is a bit clearer now. If the sctp_* calls could be
included in socket.c would be great. But if that is not possible,
I have a now way of getting this functionality using the dynamic 
library.

Let me know what you think or if you have any questions.



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Initial SCTP support for the upcoming 1.6.5 release

[Marius Vollmer]

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:

> Let me know what you think or if you have any questions.

I am now fairly convinced that we should not provide full support for
SCTP in guile-core.

The reason is simply that this support depends on libsctp which might
not be available.  Also, absence of libsctp is no good indicator that
the system does not support SCTP at all, the library might just happen
not to be installed.

We could make SCTP optional, but I really think that Guile's core API
should have as few optional pieces as possible.  Having to recompile
Guile just to get SCTP support is not right.

We could make Guile depend on libsctp, but that doesn't seem right
either.  libsctp is not essential to Guile in the way that libgmp is,
say.

Distributors such as Debian would have to decide whether to make Guile
depend on libsctp or whether to exclude sctp altogether.  Making SCTP
support an add-on to Guile avoids making this decision.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Initial SCTP support for the upcoming 1.6.5 release

[Michael Tuexen]

Marius,

that is fine. I have a library version which I will release as
soon as 1.6.5 is released.

I think this also means that I can release new version of the
lib whenever I want. This helps me because there is then no
need to wait for 1.6.6 to get new features of the SCTP stuff
accessible via guile.

However, a Linux distribution which includes SCTP (in the
kernel or as a kernel module) without providing the libsctp
is definitely broken, but this might happen. And I do not
know if anyone is checking this. I'm not doing this, since
I'm focused on BSD and Mac OS X.

Because the code for the core and the lib is pretty similar
we can include the SCTP at any time later if things change
and you think it should be included.

Thank you very much for your support.

Best regards
Michael

On Sep 8, 2004, at 17:03 Uhr, Marius Vollmer wrote:

> Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:
>
>> Let me know what you think or if you have any questions.
>
> I am now fairly convinced that we should not provide full support for
> SCTP in guile-core.
>
> The reason is simply that this support depends on libsctp which might
> not be available.  Also, absence of libsctp is no good indicator that
> the system does not support SCTP at all, the library might just happen
> not to be installed.
>
> We could make SCTP optional, but I really think that Guile's core API
> should have as few optional pieces as possible.  Having to recompile
> Guile just to get SCTP support is not right.
>
> We could make Guile depend on libsctp, but that doesn't seem right
> either.  libsctp is not essential to Guile in the way that libgmp is,
> say.
>
> Distributors such as Debian would have to decide whether to make Guile
> depend on libsctp or whether to exclude sctp altogether.  Making SCTP
> support an add-on to Guile avoids making this decision.
>



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Initial SCTP support for the upcoming 1.6.5 release

[Michael Tuexen]

Hi Marius,

I tried compiling the tarball you made.

The code uses the static:
ipv6_net_to_num
scm_addr_vector
scm_fill_sockaddr
from socket.c. For testing I just copied them from socket.c.

Then the stuff compiles but at the end of the make process the
message

make[1]: *** No rule to make target `sctp.scm', needed by `all-am'.  
Stop.
make: *** [all] Error 2

shows up.

How do I generate that sctp.scm file?

Another question:

Is there a possibility to include

#ifdef SOCK_SEQPACKET
   scm_c_define ("SOCK_SEQPACKET", SCM_MAKINUM (SOCK_SEQPACKET));
#endif

   /* protocol numbers */
#ifdef IPPROTO_SCTP
   scm_c_define ("IPPROTO_SCTP", SCM_MAKINUM (IPPROTO_SCTP));
#endif

#ifdef IPPROTO_TCP
   scm_c_define ("IPPROTO_TCP", SCM_MAKINUM (IPPROTO_TCP));
#endif

#ifdef IPPROTO_UDP
   scm_c_define ("IPPROTO_UDP", SCM_MAKINUM (IPPROTO_UDP));
#endif


to the socket.c file? These constants should be defined in
sys/socket.h and netinet/in.h.

They are not additional functions like sctp_* which are
provided in libsctp. These constants can be used with
the socket() system call you are providing in the socket.c
file.

I think your idea with putting the functions libsctp into
a guile module works and can be extended to full SCTP
support. The only problem I currently see is is with the
set/getsockopt call. Here the optvalue can be longer than
the linger option which is now hardcoded.
Is it possible to replace a function like getsockopt with
another function from a loadable module, such that I can
write a generic get/setsockopt function? Please not that
the C version does not have a restriction on the optval
length like the scheme version from socket.c has.


Best regards and thank you very much for you support
Michael

On Aug 13, 2004, at 3:40 PM, Marius Vollmer wrote:

> Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:
>
>> Please let me know if it is possible to include these changes in
>> the 1.6.5 release.
>
> Hi Michael,
>
> we don't want to include this in Guile 1.6.5.  The reason is that the
> SCTP functions are not 'core' functionality and they can take not
> advantage of being in the core.  Also, it would add another dependency
> to Guile (on libsctp).
>
> As long as SCTP needs an external library and is not supported
> directly by libc, we think it is better to not include it in
> guile-core.
>
> I have turned your patch into a complete package that installs
> libguile-net-sctp.so and the module (net sctp), you just need to fill
> in the README, etc.  Scheme code can access the new module with
>
>     (use-modules (net sctp))
>
> Unfortunately, I couldn't test it since I don't seem to have sctp
> support on my box.
>
> Here:
>
>     http://www-dt.e-technik.uni-dortmund.de/~mvo/guile-sctp-0.0.tar.gz
>



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Initial SCTP support for the upcoming 1.6.5 release

[Kevin Ryde]

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:
>
> Is there a possibility to include
>
> #ifdef SOCK_SEQPACKET
>    scm_c_define ("SOCK_SEQPACKET", SCM_MAKINUM (SOCK_SEQPACKET));
> #endif

I imagine so.

>    /* protocol numbers */
> #ifdef IPPROTO_SCTP
>    scm_c_define ("IPPROTO_SCTP", SCM_MAKINUM (IPPROTO_SCTP));
> #endif
>
> #ifdef IPPROTO_TCP
>    scm_c_define ("IPPROTO_TCP", SCM_MAKINUM (IPPROTO_TCP));
> #endif
>
> #ifdef IPPROTO_UDP
>    scm_c_define ("IPPROTO_UDP", SCM_MAKINUM (IPPROTO_UDP));
> #endif

No, I think "man 5 protocols" advises using /etc/protocols, not hard
coding numbers.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Initial SCTP support for the upcoming 1.6.5 release

[Michael Tuexen]

Dear all,

see my comments below.

Best regards
Michael

On Aug 16, 2004, at 2:40 AM, Kevin Ryde wrote:

> Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:
>>
>> Is there a possibility to include
>>
>> #ifdef SOCK_SEQPACKET
>>    scm_c_define ("SOCK_SEQPACKET", SCM_MAKINUM (SOCK_SEQPACKET));
>> #endif
>
> I imagine so.
>
Great.
>>    /* protocol numbers */
>> #ifdef IPPROTO_SCTP
>>    scm_c_define ("IPPROTO_SCTP", SCM_MAKINUM (IPPROTO_SCTP));
>> #endif
>>
>> #ifdef IPPROTO_TCP
>>    scm_c_define ("IPPROTO_TCP", SCM_MAKINUM (IPPROTO_TCP));
>> #endif
>>
>> #ifdef IPPROTO_UDP
>>    scm_c_define ("IPPROTO_UDP", SCM_MAKINUM (IPPROTO_UDP));
>> #endif
>
> No, I think "man 5 protocols" advises using /etc/protocols, not hard
> coding numbers.
Hmm. I have not seen code with does that for the last argument
of a socket() call. Normally 0 is used, which means 'select whatever
is appropiate'. For port numbers using a function call is common,
especially if the user can specify a name on the command line.
Please note that these numbers are IANA registered numbers
and you do not have a choice.

But it is your decision to include it or not.
>



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Initial SCTP support for the upcoming 1.6.5 release

[Kevin Ryde]

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:
>
>>> #ifdef SOCK_SEQPACKET
>>>    scm_c_define ("SOCK_SEQPACKET", SCM_MAKINUM (SOCK_SEQPACKET));
>>> #endif

I added that, and SOCK_RDM at the same time to both the cvs and 1.6.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Initial SCTP support for the upcoming 1.6.5 release

[Michael Tuexen]

Hi Kevin,

that is great.

I thought once again about including

   /* protocol numbers */
#ifdef IPPROTO_SCTP
   scm_c_define ("IPPROTO_SCTP", SCM_MAKINUM (IPPROTO_SCTP));
#endif

#ifdef IPPROTO_TCP
   scm_c_define ("IPPROTO_TCP", SCM_MAKINUM (IPPROTO_TCP));
#endif

#ifdef IPPROTO_UDP
   scm_c_define ("IPPROTO_UDP", SCM_MAKINUM (IPPROTO_UDP));
#endif

in socket.c. The argument, to use a function like getprotobyname
to perform a lookup in /etc/protocols, is not valid in my opinion.
The reason is, that besides I have not seen that, that  the
constants above are defined in /usr/include/netinet/in.h and
are used. So if, a system (I do not know of any such system),
uses a different number for TCP, this number will not only be in
/etc/protocols, but also in /usr/include/netinet/in.h. A different
story are port numbers. They can (and should) be looked up in 
/etc/services.
There are no constants describing the port number for an echo server...

Best regards
Michael


On Aug 18, 2004, at 1:46 AM, Kevin Ryde wrote:

> Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:
>>
>>>> #ifdef SOCK_SEQPACKET
>>>>    scm_c_define ("SOCK_SEQPACKET", SCM_MAKINUM (SOCK_SEQPACKET));
>>>> #endif
>
> I added that, and SOCK_RDM at the same time to both the cvs and 1.6.
>



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Initial SCTP support for the upcoming 1.6.5 release

[Kevin Ryde]

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:
>
> The argument, to use a function like getprotobyname
> to perform a lookup in /etc/protocols, is not valid in my opinion.
> The reason is, that besides I have not seen that, that  the
> constants above are defined in /usr/include/netinet/in.h and
> are used.

I don't want to go against the advice of the GNU/Linux man page.  It's
pretty explicit.

> So if, a system (I do not know of any such system),
> uses a different number for TCP, this number will not only be in
> /etc/protocols, but also in /usr/include/netinet/in.h. A different
> story are port numbers. They can (and should) be looked up in
> /etc/services.
> There are no constants describing the port number for an echo server...

Well I guess both protocol and service numbers for standard stuff are
constants.  I don't know why one reads a file instead of just putting
numbers in a program.  Maybe it dates right back to a time when such
things were still in flux.  Or maybe the theory is to avoid numbers
hard coded in programs (though strings hard coded aren't much better
:-).


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Initial SCTP support for the upcoming 1.6.5 release

[Michael Tuexen]

Kevin,

see my comments in-line.

Best regards
Michael

On Aug 20, 2004, at 3:13 AM, Kevin Ryde wrote:

> Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:
>>
>> The argument, to use a function like getprotobyname
>> to perform a lookup in /etc/protocols, is not valid in my opinion.
>> The reason is, that besides I have not seen that, that  the
>> constants above are defined in /usr/include/netinet/in.h and
>> are used.
>
> I don't want to go against the advice of the GNU/Linux man page.  It's
> pretty explicit.
You are not going against it. You are not using them. You are only
providing constants available in /usr/include/netinet/in.h to
the guile user.
>
>> So if, a system (I do not know of any such system),
>> uses a different number for TCP, this number will not only be in
>> /etc/protocols, but also in /usr/include/netinet/in.h. A different
>> story are port numbers. They can (and should) be looked up in
>> /etc/services.
>> There are no constants describing the port number for an echo  
>> server...
>
> Well I guess both protocol and service numbers for standard stuff are
> constants.  I don't know why one reads a file instead of just putting
> numbers in a program.  Maybe it dates right back to a time when such
> things were still in flux.  Or maybe the theory is to avoid numbers
> hard coded in programs (though strings hard coded aren't much better
> :-).
You are right, both port numbers and protocol numbers are kind of
standardized. But there is two differences:
Normally a user of a program does not specify the transport protocol,
but the port (telnet 127.0.0.1 echo, for example). That is why you
need a translation service for these service names.
The second is that there are no predefined constants for port numbers
available on a system like it is for protocols.
I agree with the man page that it is bad to use
s = socket(AF_INET, SOCK_STREAM, 132);
It should be
s = socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP);
because you are not using a number, you are using a constant.

So what is the difference if you use getprotocolbyname? You can move
the binaries to a different host which uses different numbers?
I have not seen that and I'm pretty sure that this is not in tune
with the socket() call.

BTW, for UDP and TCP the calls
s = socket(AF_INET, SOCK_DGRAM,  0);
s = socket(AF_INET, SOCK_STREAM, 0);
are used as acronyms for
s = socket(AF_INET, SOCK_DGRAM,  IPPROTO_UDP);
s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);

So I think the man page and reality match no pretty good for these  
things,
but the man page seems to be pretty old (1995, on
http://www.freebsd.org/cgi/man.cgi? 
query=protocols&apropos=0&sektion=0&manpath=Red+Hat+Linux%2Fi386+9&forma 
t=html

Best regards
Michael

PS.: The usage of the third arg of the socket() call is the one  
described
      in the 3rd edition of Unix Network Programming, so I guess that  
some
      people will try to use it that way...




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Initial SCTP support for the upcoming 1.6.5 release

[Michael Tuexen]

Dear all,

I'm trying to build the SCTP support as a loadable module.

Is there any documentation available (or an example) where
I can figure out how I can solve the questions described
below.

I looked in the guile sources, but only found modules defined
in scheme...

Thank you very much for your help.

Best regards
Michael

On Aug 14, 2004, at 11:59 AM, Michael Tuexen wrote:

> Hi Marius,
>
> I tried compiling the tarball you made.
>
> The code uses the static:
> ipv6_net_to_num
> scm_addr_vector
> scm_fill_sockaddr
> from socket.c. For testing I just copied them from socket.c.
>
> Then the stuff compiles but at the end of the make process the
> message
>
> make[1]: *** No rule to make target `sctp.scm', needed by `all-am'.  
> Stop.
> make: *** [all] Error 2
>
> shows up.
>
> How do I generate that sctp.scm file?
>
> Another question:
>
> Is there a possibility to include
>
> #ifdef SOCK_SEQPACKET
>   scm_c_define ("SOCK_SEQPACKET", SCM_MAKINUM (SOCK_SEQPACKET));
> #endif
>
>   /* protocol numbers */
> #ifdef IPPROTO_SCTP
>   scm_c_define ("IPPROTO_SCTP", SCM_MAKINUM (IPPROTO_SCTP));
> #endif
>
> #ifdef IPPROTO_TCP
>   scm_c_define ("IPPROTO_TCP", SCM_MAKINUM (IPPROTO_TCP));
> #endif
>
> #ifdef IPPROTO_UDP
>   scm_c_define ("IPPROTO_UDP", SCM_MAKINUM (IPPROTO_UDP));
> #endif
>
>
> to the socket.c file? These constants should be defined in
> sys/socket.h and netinet/in.h.
>
> They are not additional functions like sctp_* which are
> provided in libsctp. These constants can be used with
> the socket() system call you are providing in the socket.c
> file.
>
> I think your idea with putting the functions libsctp into
> a guile module works and can be extended to full SCTP
> support. The only problem I currently see is is with the
> set/getsockopt call. Here the optvalue can be longer than
> the linger option which is now hardcoded.
> Is it possible to replace a function like getsockopt with
> another function from a loadable module, such that I can
> write a generic get/setsockopt function? Please not that
> the C version does not have a restriction on the optval
> length like the scheme version from socket.c has.
>
>
> Best regards and thank you very much for you support
> Michael
>
> On Aug 13, 2004, at 3:40 PM, Marius Vollmer wrote:
>
>> Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:
>>
>>> Please let me know if it is possible to include these changes in
>>> the 1.6.5 release.
>>
>> Hi Michael,
>>
>> we don't want to include this in Guile 1.6.5.  The reason is that the
>> SCTP functions are not 'core' functionality and they can take not
>> advantage of being in the core.  Also, it would add another dependency
>> to Guile (on libsctp).
>>
>> As long as SCTP needs an external library and is not supported
>> directly by libc, we think it is better to not include it in
>> guile-core.
>>
>> I have turned your patch into a complete package that installs
>> libguile-net-sctp.so and the module (net sctp), you just need to fill
>> in the README, etc.  Scheme code can access the new module with
>>
>>     (use-modules (net sctp))
>>
>> Unfortunately, I couldn't test it since I don't seem to have sctp
>> support on my box.
>>
>> Here:
>>
>>     http://www-dt.e-technik.uni-dortmund.de/~mvo/guile-sctp-0.0.tar.gz
>>
>
>
>
> _______________________________________________
> Guile-devel mailing list
> Guile-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/guile-devel
>



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Initial SCTP support for the upcoming 1.6.5 release

[Rob Browning]

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:

> I'm trying to build the SCTP support as a loadable module.
>
> Is there any documentation available (or an example) where
> I can figure out how I can solve the questions described
> below.
>
> I looked in the guile sources, but only found modules defined
> in scheme...

In general, C-only modules are deprecated.  The recommendation is that
you create a small .scm file for your module, and then have that load
your shared library and export your symbols, i.e.:

  (define-module (pcre))
  ;; exports at end of file.

  (let ((lib "libguile-pcre-v-1")
        (init-func "libguile_pcre_init"))
    (if (string=? (substring (version) 0 3) "1.4")
        (dynamic-call init-func (dynamic-link lib))
        (load-extension lib init-func)))

  ;; make any scheme side defines you that want to here.

  ;; export things here (though you could also do this above, or in
  ;; the define-module statement)

  ;; these exports will often be symbols that were defined during your
  ;; _init function above

  (export PCRE_MAJOR)
  (export PCRE_MINOR)
  ...

Now, presuming that your .scm file is in the %load-path (via
GUILE_LOAD_PATH, or whatever), and your shared library is in the
LD_LIBRARY_PATH (or default ld.so locations), then (use-modules
(pcre)) should work just fine.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Initial SCTP support for the upcoming 1.6.5 release

[Michael Tuexen]

Hi Rob,

I got the external library from Marius compiled and
wrote sctp.scm such that the net_sctp_init can
be called and the constants can be accessed.

But I have two functions defined, one of them is defined
by

SCM_DEFINE (net_sctp_recvmsg, "sctp-recvmsg!", 2, 2, 0,
             (SCM sock, SCM str, SCM start, SCM end),
	    "Return data from the socket port @var{sock} and also\n"
	    "information about where the data was received from.\n"
	    "@var{sock} must already be bound to the address from which\n"
	    "data is to be received.  @code{str}, is a string into which the\n"
	    "data will be written.  The size of @var{str} limits the amount\n"
	    "of data which can be received: in the case of packet protocols,\n"
	    "if a packet larger than this limit is encountered then some\n"
	    "data will be irrevocably lost.\n\n"
	    "The value returned is a list containing:\n"
	    "- the number of bytes read from the socket\n"
	    "- an address object in the same form as returned by 
@code{accept}\n"
	    "- the flags returned by the sctp_recvmsg call\n"
	    "- a list containing the SID, SSN, PPID, TSN and CUM_TSN\n"
	    "The @var{start} and @var{end} arguments specify a substring of\n"
	    "@var{str} to which the data should be written.\n\n"
	    "Note that the data is read directly from the socket file\n"
	    "descriptor: any unread buffered port data is ignored.")
#define FUNC_NAME s_net_sctp_recvmsg
{
   int rv;
....
   return scm_list_4 (SCM_MAKINUM (rv), address, SCM_MAKINUM (flg), 
s_sinfo);
}
#undef FUNC_NAME


How can I access this function from scheme?


Another question:
I need
ipv6_net_to_num
scm_addr_vector
scm_fill_sockaddr
which are declared static in socket.c. Can they made available and not
be declared static? If not, I need to define them again, which is not
very elegant.

And the last question:
Could the setsockopt and getsockopt functions be extended such that
they support an arbitrary length opt_value? This is the way they are
defined in C. What should the scheme type for the opt_value? A string?

Thank you very much for your help.

Best regards
Michael

On Aug 16, 2004, at 8:44 PM, Rob Browning wrote:

> Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:
>
>> I'm trying to build the SCTP support as a loadable module.
>>
>> Is there any documentation available (or an example) where
>> I can figure out how I can solve the questions described
>> below.
>>
>> I looked in the guile sources, but only found modules defined
>> in scheme...
>
> In general, C-only modules are deprecated.  The recommendation is that
> you create a small .scm file for your module, and then have that load
> your shared library and export your symbols, i.e.:
>
>   (define-module (pcre))
>   ;; exports at end of file.
>
>   (let ((lib "libguile-pcre-v-1")
>         (init-func "libguile_pcre_init"))
>     (if (string=? (substring (version) 0 3) "1.4")
>         (dynamic-call init-func (dynamic-link lib))
>         (load-extension lib init-func)))
>
>   ;; make any scheme side defines you that want to here.
>
>   ;; export things here (though you could also do this above, or in
>   ;; the define-module statement)
>
>   ;; these exports will often be symbols that were defined during your
>   ;; _init function above
>
>   (export PCRE_MAJOR)
>   (export PCRE_MINOR)
>   ...
>
> Now, presuming that your .scm file is in the %load-path (via
> GUILE_LOAD_PATH, or whatever), and your shared library is in the
> LD_LIBRARY_PATH (or default ld.so locations), then (use-modules
> (pcre)) should work just fine.
>
> -- 
> Rob Browning
> rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
> GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 
> 8C7E 73A4
>



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Initial SCTP support for the upcoming 1.6.5 release

[Kevin Ryde]

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:
>
> Could the setsockopt and getsockopt functions be extended such that
> they support an arbitrary length opt_value?

The best is for the guile code to understand the data passed so it can
do a sensible conversion.  You'll have to say what you're trying to
use.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Initial SCTP support for the upcoming 1.6.5 release

[Michael Tuexen]

Hi Kevin,

the problem is that this function is defined in socket.c and the 
structures
I'm interested in are SCTP specific. As far as I understood the comments
on the list it is not appropriate that SCTP stuff is used that fil (or
in guile at all).

Since the set/getsockopt function does not reference any specific 
structure
it would be a possibility of have it provided as generic as it is in C 
and
I would write some scheme functions to transfer the SCTP specific data
into the generic one. This would allow me to provide a C based module to
provide SCTP functionality without using my own version guile which I
want to avoid, because it is difficult for me to test all the platforms.

BTW, do you know how handle a function like

SCM_DEFINE (net_sctp_recvmsg, "sctp-recvmsg!", 2, 2, 0,
             (SCM sock, SCM str, SCM start, SCM end),
	    "Return data from the socket port @var{sock} and also\n"
....
	    "descriptor: any unread buffered port data is ignored.")
#define FUNC_NAME s_net_sctp_recvmsg
{
   int rv;
....
   return scm_list_4 (SCM_MAKINUM (rv), address, SCM_MAKINUM (flg), 
s_sinfo);
}
#undef FUNC_NAME

in a module? I have not found an example for C based modules for guile 
yet.
Everything distributed with guile is scheme based, I think.

Best regards
Michael

On Aug 23, 2004, at 2:58 AM, Kevin Ryde wrote:

> Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:
>>
>> Could the setsockopt and getsockopt functions be extended such that
>> they support an arbitrary length opt_value?
>
> The best is for the guile code to understand the data passed so it can
> do a sensible conversion.  You'll have to say what you're trying to
> use.
>



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Initial SCTP support for the upcoming 1.6.5 release

[Kevin Ryde]

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:
>
> Since the set/getsockopt function does not reference any specific
> structure
> it would be a possibility of have it provided as generic as it is in C
> and
> I would write some scheme functions to transfer the SCTP specific data
> into the generic one.

It's probably better to make replacement functions that do their
specifics then call the core.

(If there were many semi-independent modules going to do that then
some sort of hook arrangement would be better, but a replacement will
work initially at least.)

> I have not found an example for C based modules for guile yet.

load-extension I think, per "A Sample Guile Extension" and "Putting
Extensions into Modules" in the manual.  More indexing in the manual
might help when looking for such stuff.

> Everything distributed with guile is scheme based, I think.

Cf srfi/srfi-13 and 14, and guile-readline/ice-9/readline.scm.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Initial SCTP support for the upcoming 1.6.5 release

[Michael Tuexen]

Kevin,

see my comments below.

Best regards
Michael

On Aug 24, 2004, at 2:57 AM, Kevin Ryde wrote:

> Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:
>>
>> Since the set/getsockopt function does not reference any specific
>> structure
>> it would be a possibility of have it provided as generic as it is in C
>> and
>> I would write some scheme functions to transfer the SCTP specific data
>> into the generic one.
>
> It's probably better to make replacement functions that do their
> specifics then call the core.
>
> (If there were many semi-independent modules going to do that then
> some sort of hook arrangement would be better, but a replacement will
> work initially at least.)
So I just define my own setsockopt and it will 'overwrite' the existing
one. That'll work. I was not sure if I can just define another function
with the same name and that will overwrite the existing one.
>
>> I have not found an example for C based modules for guile yet.
>
> load-extension I think, per "A Sample Guile Extension" and "Putting
> Extensions into Modules" in the manual.  More indexing in the manual
> might help when looking for such stuff.
I was looking at

http://www.gnu.org/software/guile/docs/guile-ref/Dynamic- 
Libraries.html#Dynamic%20Libraries

under the title "Modules"
not at "A Whirlwind Tour" where I find under
http://www.gnu.org/software/guile/docs/guile-ref/A-Sample-Guile- 
Extension.html#A%20Sample%20Guile%20Extension
the Extension stuff... Thank you very much for the hint.

>
>> Everything distributed with guile is scheme based, I think.
>
> Cf srfi/srfi-13 and 14, and guile-readline/ice-9/readline.scm.
Ahh. I have not found them. I was looking at ice-9...

Thank you very much for your help.
>



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Initial SCTP support for the upcoming 1.6.5 release

[Michael Tuexen]

Dear all,

with the hints of Kevin I got my stuff working.

I need besides the static functions from socket.c the
SCM_SYSCALL stuff from libguile/_scm.h. This is file is
not installed. So is there a chance to move the SCM_SYSCALL
stuff from _scm.h to __scm.h? If not, I have to duplicate
the code, which is not a problem...

I have another question: How can I make the documentation included
in the SCM_DEFINE makro available from scheme. My C code contains

SCM_DEFINE (net_sctp_sendmsg, "sctp-sendmsg", 8, 0, 1,
             (SCM sock, SCM message, SCM ppid, SCM stream_no, SCM ttl,  
SCM context, SCM fam, SCM address, SCM args_and_flags),
	    "Transmit the string @var{message} on the socket port\n"
	    "@var{sock}.  The\n"
	    "parameters @var{ppid}, @var{stream_no}, @var{ttl} and   
@var{context}\n"
	    "are the corresponding SCTP parameters. The\n"
	    "destination address is specified using the @var{fam},\n"
	    "@var{address} and\n"
	    "@var{args_and_flags} arguments, in a similar way to the\n"
	    "@code{connect} procedure.  @var{args_and_flags} contains\n"
	    "the usual connection arguments optionally followed by\n"
	    "a flags argument, which is a value or\n"
	    "bitwise OR of MSG_UNORDERED, MSG_ABORT, MSG_EOF etc.\n\n"
	    "The value returned is the number of bytes transmitted\n"
	    "Note that the data is written directly to the socket\n"
	    "file descriptor:\n"
	    "any unflushed buffered port data is ignored.")
#define FUNC_NAME s_net_sctp_sendmsg
{
   /* missing the code */
   return SCM_MAKINUM (rv);
}
#undef FUNC_NAME


but on the scheme side it is not available like the documentation
for the socket() call, which is defined in libguile/socket.c:

guile> (use-modules (net sctp))
guile> (help socket)
`socket' is a primitive procedure in the (guile) module.

  - Scheme Procedure: socket family style proto
      Return a new socket port of the type specified by FAMILY, STYLE
      and PROTO.  All three parameters are integers.  Supported values
      for FAMILY are `AF_UNIX', `AF_INET' and `AF_INET6'.  Typical
      values for STYLE are `SOCK_STREAM', `SOCK_DGRAM' and `SOCK_RAW'.

      PROTO can be obtained from a protocol name using `getprotobyname'.
      A value of zero specifies the default protocol, which is usually
      right.

      A single socket port cannot by used for communication until it has
      been connected to another socket.


guile> (help sctp-sendmsg)
No documentation found for:
(net sctp): sctp-sendmsg

Thank you very much for your help.

Best regards
Michael

On Aug 24, 2004, at 1:27 PM, Michael Tuexen wrote:

> Kevin,
>
> see my comments below.
>
> Best regards
> Michael
>
> On Aug 24, 2004, at 2:57 AM, Kevin Ryde wrote:
>
>> Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:
>>>
>>> Since the set/getsockopt function does not reference any specific
>>> structure
>>> it would be a possibility of have it provided as generic as it is in  
>>> C
>>> and
>>> I would write some scheme functions to transfer the SCTP specific  
>>> data
>>> into the generic one.
>>
>> It's probably better to make replacement functions that do their
>> specifics then call the core.
>>
>> (If there were many semi-independent modules going to do that then
>> some sort of hook arrangement would be better, but a replacement will
>> work initially at least.)
> So I just define my own setsockopt and it will 'overwrite' the existing
> one. That'll work. I was not sure if I can just define another function
> with the same name and that will overwrite the existing one.
>>
>>> I have not found an example for C based modules for guile yet.
>>
>> load-extension I think, per "A Sample Guile Extension" and "Putting
>> Extensions into Modules" in the manual.  More indexing in the manual
>> might help when looking for such stuff.
> I was looking at
>
> http://www.gnu.org/software/guile/docs/guile-ref/Dynamic- 
> Libraries.html#Dynamic%20Libraries
>
> under the title "Modules"
> not at "A Whirlwind Tour" where I find under
> http://www.gnu.org/software/guile/docs/guile-ref/A-Sample-Guile- 
> Extension.html#A%20Sample%20Guile%20Extension
> the Extension stuff... Thank you very much for the hint.
>
>>
>>> Everything distributed with guile is scheme based, I think.
>>
>> Cf srfi/srfi-13 and 14, and guile-readline/ice-9/readline.scm.
> Ahh. I have not found them. I was looking at ice-9...
>
> Thank you very much for your help.
>>
>
>
>
> _______________________________________________
> Guile-devel mailing list
> Guile-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/guile-devel
>



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Initial SCTP support for the upcoming 1.6.5 release

[Marius Vollmer]

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:

> with the hints of Kevin I got my stuff working.

Excellent, and please accept my apologies for doing such a louse job
with the first attempt.  I forgot to include sctp.scm in the tarball,
here it is for reference:

    (define-module (net sctp))

    (export sctp-recvmsg!
            sctp-sendmsg

            SOCK_SEQPACKET

            IPPROTO_SCTP
            IPPROTO_TCP
            IPPROTO_UDP

            MSG_UNORDERED
            MSG_ADDR_OVER
            MSG_ABORT
            MSG_EOF
            MSG_EOR
            MSG_NOTIFICATION
            MSG_PR_SCTP_TTL
            MSG_PR_SCTP_BUF)

    (load-extension "libguile-net-sctp" "net_sctp_init")

> I need besides the static functions from socket.c the
> SCM_SYSCALL stuff from libguile/_scm.h. This is file is
> not installed. So is there a chance to move the SCM_SYSCALL
> stuff from _scm.h to __scm.h? If not, I have to duplicate
> the code, which is not a problem...

Yes, please duplicate.  SCM_SYSCALL is more of an internal helper for
boilerplate code that unrelated to Guile.

> I have another question: How can I make the documentation included
> in the SCM_DEFINE makro available from scheme.

I don't think there is a good way yet.  Which is really bad, bad, bad,
I know.  Leave your docstring in place and hope that you will soon be
able to use it.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Initial SCTP support for the upcoming 1.6.5 release

[Michael Tuexen]

Marius,

see my comments in-line.

Best regards
Michael

On Aug 24, 2004, at 4:24 PM, Marius Vollmer wrote:

> Michael Tuexen <Michael.Tuexen@lurchi.franken.de> writes:
>
>> with the hints of Kevin I got my stuff working.
>
> Excellent, and please accept my apologies for doing such a louse job
> with the first attempt.  I forgot to include sctp.scm in the tarball,
> here it is for reference:
No problem. I did not figured out that I had to use load-extension.
I was playing with dynamic-args-call from
http://www.gnu.org/software/guile/docs/guile-ref/Low-level-dynamic- 
linking.html#Low%20level%20dynamic%20linking
which was not that appropriate.
>
>     (define-module (net sctp))
>
>     (export sctp-recvmsg!
>             sctp-sendmsg
>
>             SOCK_SEQPACKET
>
>             IPPROTO_SCTP
>             IPPROTO_TCP
>             IPPROTO_UDP
>
>             MSG_UNORDERED
>             MSG_ADDR_OVER
>             MSG_ABORT
>             MSG_EOF
>             MSG_EOR
>             MSG_NOTIFICATION
>             MSG_PR_SCTP_TTL
>             MSG_PR_SCTP_BUF)
>
>     (load-extension "libguile-net-sctp" "net_sctp_init")
>
>> I need besides the static functions from socket.c the
>> SCM_SYSCALL stuff from libguile/_scm.h. This is file is
>> not installed. So is there a chance to move the SCM_SYSCALL
>> stuff from _scm.h to __scm.h? If not, I have to duplicate
>> the code, which is not a problem...
>
> Yes, please duplicate.  SCM_SYSCALL is more of an internal helper for
> boilerplate code that unrelated to Guile.
OK.
>
>> I have another question: How can I make the documentation included
>> in the SCM_DEFINE makro available from scheme.
>
> I don't think there is a good way yet.  Which is really bad, bad, bad,
> I know.  Leave your docstring in place and hope that you will soon be
> able to use it.
OK. I was not sure if I had to do something 'magic' in the sctp.scm
file.
>



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel