[comp.protocols.iso.dev-environ] FTAM presentation user data size

old@sunbim.UUCP (Olivier Dubois) (08/10/90)

Some weeks ago I sent an article on incompatibility between the isode FTAM
implementation and M1/T1/A/111 profile compliant implementation.
The isode responder as well as the initiator can generate too big presentation
data value for other implementation to decode. I added a test in the code to
limit the size of PDV.
The files ftam-put.c and ftamd-trans.c in the ftam2 directory are to be modified
I used the isode-5.9 code.

in ftam-put.c, in the put() function, after the lines:
	.
	.
#ifdef	BRIDGE
    bsize = BUFSIZ << 2;
    size = magic >= bsize ? magic : bsize;
    if (size > bsize)
	size -= size % bsize;
#else
#ifndef	MAXBSIZE
    bsize = BUFSIZ;
#else
    bsize = st.st_blksize > 0 ? st.st_blksize : BUFSIZ;
#endif
    size = (1024 <= magic && magic < bsize) ? magic : bsize;
#endif


add :
/*       90/08/10
	added by Olivier Dubois, BIM, Everberg, Belgium to conform
	to ftam profile T1 or A/111 and derivatives where the FTAM user data
	is limited to 7K. Conformant implementation can crash receiving to big
	Presentation data value. This prevent from putting files  bigger than 7K 
        to their filestore. This is a simple hack to allow interoperability with
	conformant implementations. The limitation could be done fragmenting 
	presentation element in the FDataRequest library function. It is the file
	sender which decide the P-Data bound in the transfer, it is safe only to 
        modify the sender functions.
	the same modification has to be made to the responder function uxfget in
         ftamd-trans.c..
	the bridge case has to be checked against this problem.
*/
#define	FTAM_MAX_USER_DATA  4096 /* I choose 4K as 7k is the maximum decoded 
				     user data size, you have to keep a few 
				     headroom bytes for the receiver ( 100 from 
				     experience ). So why not stay with a power 
				      2 for faster buffering)
				  */

    if ( size > FTAM_MAX_USER_DATA )
       switch (vf - vfs) {
	  case VFS_UTF: 
	    size =  FTAM_MAX_USER_DATA + MAGIC_OCTET1;
	    break;

	  case VFS_UBF:
	  default:
	    size =  FTAM_MAX_USER_DATA + MAGIC_SINGLE;
	    break;
    }


/* end addition */
 
and apply the some modification in the file ftamd-trans.c in the function 
ufxget().
I hope someone can find this patch usefull and I always interessted to hear
your feelings about that damned file transfer protocol.

Olivier Dubois,
System engineer,
BIM sa/nv, Belgium.

old@sunbim.UUCP (Olivier Dubois) (08/10/90)

Newsgroups: comp.protocols.iso.dev-environ
Subject: FTAM presentation user data size
Expires: 
References: 
Sender: Olivier Dubois 
Reply-To: old@sunbim.be (Olivier Dubois)
Distribution: world
Organization: BIM Everberg Belgium
Keywords: 

Some weeks ago I sent an article on incompatibility between the isode FTAM
implementation and M1/T1/A/111 profile compliant implementation.
The isode responder as well as the initiator can generate too big presentation
data value for other implementation to decode. I added a test in the code to
limit the size of PDV.
The files ftam-put.c and ftamd-trans.c in the ftam2 directory are to be modified
I used the isode-5.9 code.

in ftam-put.c, in the put() function, after the lines:
	.
	.
#ifdef	BRIDGE
    bsize = BUFSIZ << 2;
    size = magic >= bsize ? magic : bsize;
    if (size > bsize)
	size -= size % bsize;
#else
#ifndef	MAXBSIZE
    bsize = BUFSIZ;
#else
    bsize = st.st_blksize > 0 ? st.st_blksize : BUFSIZ;
#endif
    size = (1024 <= magic && magic < bsize) ? magic : bsize;
#endif


add :
/*       90/08/10
	added by Olivier Dubois, BIM, Everberg, Belgium to conform
	to ftam profile T1 or A/111 and derivatives where the FTAM user data
	is limited to 7K. Conformant implementation can crash receiving to big
	Presentation data value. This prevent from putting files  bigger than 7K 
        to their filestore. This is a simple hack to allow interoperability with
	conformant implementations. The limitation could be done fragmenting 
	presentation element in the FDataRequest library function. It is the file
	sender which decide the P-Data bound in the transfer, it is safe only to 
        modify the sender functions.
	the same modification has to be made to the responder function uxfget in
         ftamd-trans.c..
	the bridge case has to be checked against this problem.
*/
#define	FTAM_MAX_USER_DATA  4096 /* I choose 4K as 7k is the maximum decoded 
				     user data size, you have to keep a few 
				     headroom bytes for the receiver ( 100 from 
				     experience ). So why not stay with a power 
				      2 for faster buffering)
				  */

    if ( size > FTAM_MAX_USER_DATA )
       switch (vf - vfs) {
	  case VFS_UTF: 
	    size =  FTAM_MAX_USER_DATA + MAGIC_OCTET1;
	    break;

	  case VFS_UBF:
	  default:
	    size =  FTAM_MAX_USER_DATA + MAGIC_SINGLE;
	    break;
    }


/* end addition */
 
and apply the some modification in the file ftamd-trans.c in the function 
ufxget().
I hope someone can find this patch usefull and I always interessted to hear
your feelings about that damned file transfer protocol.

Olivier Dubois,
System engineer,
BIM sa/nv, Belgium.

mrose@CHEETAH.NYSER.NET (Marshall Rose) (08/12/90)

You really should use the bug-isode address.

This is the first time I have seen your message.

A fix will be made.

/mtr