Subject: Re: LARGE_READX / LARGE_WRITEX support - msg#00084

Previous Message by Date: click to view message preview

Re: Re: Disconnect from a share

On Wed, 19 Oct 2005 12:51:51 +0000 (UTC) Alexander Saupp <asaupp@xxxxxx> wrote: > >If JCIFS has an existing session with the desired domain and username > >then probably not. It will simply reuse the existing session even with > >jcifs.smb.client.ssnLimit=1. You would have to use different credentials > >each time you query to ensure that a new transport is created. > > You might be right for the session - but the transport is definitly a > new one. > public class SmbTransport extends Transport implements SmbConstants { > ... > static synchronized SmbTransport getSmbTransport( UniAddress address, > int port, InetAddress localAddr, int localPort ) { > ... > if( SSN_LIMIT != 1 ) { > .. > } > conn = new SmbTransport( address, port, localAddr, localPort ); You're assuming getSmbTransport is being called each time a new session is created. It is not. I'll try your test program but it might take me a while. Mike

Next Message by Date: click to view message preview

Re: Disconnect from a share

Levi Purvis <mail <at> levipurvis.com> writes: > I'm not very familiar with the internals of the JCIFS code, but in > general it is fairly easy to create a dedicated "logoff" thread to fix > this problem. Rather than rudely closing the socket, execute the code > for reading the "logoff" response and closing the socket on a separate > thread. This way the rest of the code doesn't have to wait, but the > other end won't get the "Connection reset by peer" problem. You may > only need one thread to act as a "sink" for cleaning up, so > performance should be comparable to the current code. Throw in NIO, > and it will be even better. A thread pool might be in order if > many concurrent logoff responses are expected and NIO is not an > option, to avoid having sockets that need closing pile up. Thanks for racking my brains :-) Would you have some details on the 'logoff thread' you propose? How would i 'logoff'? The main point I am trying to be strict is that i want to be sure the first session (samba service check) is really closed on server side before i run the second service type (check) - having a seperate thread doing the logoff doesn't sound like the approach giving a guaranteed close confirmation to me? Bye, Alex

Previous Message by Thread: click to view message preview

Re: LARGE_READX / LARGE_WRITEX support

The fixes are great. I'll have to look at Encdec closely. Thanks. I'll put the LARGE_{READ,WRITE}X in my todo folder. I seem to recall rejecting a patch for this a while back but I don't recall why. Mike On Wed, 19 Oct 2005 17:03:34 +0200 Thomas Krammer <Thomas_Krammer@xxxxxxxx> wrote: > Hi, > > the attached patch adds LARGE_READX / LARGE_WRITEX support to jCIFS > 1.2.6. It also fixes some problems I found along the way. > > 1) Debug output in Transport.java > > The patch removes some debug output that is printed to stdout. > > 2) Integer overflow in SmbTransport.java > > If you execute the following code: > > SmbFile serverFile = .... > SmbRandomAccessFile ra = new SmbRandomAccessFile(serverFile, "rw"); > > int BUFFER_SIZE = Short.MAX_VALUE; > > byte[] buffer = new byte[BUFFER_SIZE]; > > ra.read(buffer); > > you will get the following exception: > > jcifs.util.transport.TransportException: Transport1 timedout waiting for > response to > SmbComReadAndX[command=SMB_COM_READ_ANDX,received=false,errorCode=0,flags=0x0018,flags2=0xC003,signSeq=0,tid=2048,pid=10207,uid=2048,mid=475,wordCount=12,byteCount=0,andxCommand=0xFF,andxOffset=0,fid=16384,offset=0,maxCount=32767,minCount=32767,openTimeout=-1,remaining=0,offset=0] > at jcifs.util.transport.Transport.sendrecv(Transport.java:74) > at jcifs.smb.SmbTransport.send(SmbTransport.java:580) > at jcifs.smb.SmbSession.send(SmbSession.java:229) > at jcifs.smb.SmbTree.send(SmbTree.java:102) > at jcifs.smb.SmbFile.send(SmbFile.java:688) > at jcifs.smb.SmbRandomAccessFile.read(SmbRandomAccessFile.java:86) > at jcifs.smb.SmbRandomAccessFile.read(SmbRandomAccessFile.java:69) > > The reason for this error is an integer overflow in > SmbTransport.doRecv() line 422. If the specified buffer size is greater > than Short.MAX_VALUE - SMB_HEADER_LENGTH the package size gets negative > and the package is rejected. That's because Encdec.dec_uint16be returns > a short instead of an int. > > Please note that there are more similar errors in Encdec (for example > dec_uint32be returns an int instead of a long). I didn't fix those > additional errors. > > 3) LARGE_READX and LARGE_WRITEX support > > The patch adds LARGE_READX and LARGE_WRITEX support for > SmbFileInputStream, SmbFileOutputStream and SmbRandomAccessFile. This > significantly increases the performance when transferring files from and > to Windows servers. > > For example transferring a 183 MB file (using streams): > > modified 1.2.6 original 1.2.6 > Download 23 sec 39 sec > Upload 26 sec 40 sec > > Client: Windows XP SP 2, Java 1.4.2_08 > Server: Windows XP SP 2 > > The test used a 128k buffer to transfer the data from the InputStream to > the OutputStream. > > > Bye, > > Thomas > >

Next Message by Thread: click to view message preview

RE: LARGE_READX / LARGE_WRITEX support

> From: > jcifs-bounces+chuck.caldarale=unisys.com@xxxxxxxxxxxxxxx > [mailto:jcifs-bounces+chuck.caldarale=unisys.com@xxxxxxxxxxxxxxx] > On Behalf Of Michael B Allen > Subject: Re: [jcifs] LARGE_READX / LARGE_WRITEX support > > I seem to recall rejecting a patch for this a while back but > I don't recall why. I don't know if it's related, but we've had problems with the LARGE_*X commands on some versions of Windows, and currently have the capability bits disabled in our mainframe CIFS server and client unless we're talking to a known well-behaved system (e.g., one of our own). I remember things like the Windows client only half-implementing the LARGE_*X protocol, and trying to put a byte count of 65536 into a 16-bit field. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.