Hello

I modified the CLIENT/SERVER examples to send the contents of a file from
the server to the client but the client doesn't receives only the first 6Kb
(more or less) of the string the server sends
Why?
the docs for socketsend says that only if UDP is used there is size limit of
the string to send

Another question: how secure is sending/receiving  the strings  like the
CLIENT/SERVER examples? there should be some CRC check on the strings? or
this is managed internally by the function send/recv?

thanks
Simone

I was just about going home when I found following message in the newsgroup  :

"Simone Degl'Innocenti" <simone.degl@tin.it> schrieb im Newsbeitrag
news:3bb18398@asgcom.alaska-software.com...
> Hello
>
> I modified the CLIENT/SERVER examples to send the contents of a file from
> the server to the client but the client doesn't receives only the first 6Kb
> (more or less) of the string the server sends
> Why?
> the docs for socketsend says that only if UDP is used there is size limit of
> the string to send

Please send some lines of code describing the changes you have done.
When using stream sockets there is no limitation in length. Just for fun I have written a small application
which sent
2 MB and 4MB of data through the network. I have had a lot of trouble with it, but none of these problems
could be
reduced to a socket issue.

> Another question: how secure is sending/receiving  the strings  like the
> CLIENT/SERVER examples? there should be some CRC check on the strings? or
> this is managed internally by the function send/recv?

Such things are managed by the lowlevel protocols. Between two pieces of hardware the ethernet protocol is
responsible for example. Between sockets, the IP protocol is responsible.
You need not worry about such questions, otherwise the internet would not be as successfull as it is today.




--


Andreas Herdt
Alaska Software Technology AG

-------------------------------------------------------------
Technical Support EMEA: mailto:support@de.alaska-software.com
Technical Support APRA: mailto:support@us.alaska-software.com
News Server:            news://news.alaska-software.com
Homepage:               http://www.alaska-software.com
-------------------------------------------------------------

"Andreas Herdt" <ah@de.alaska-software.com> ha scritto nel messaggio
news:3bb34b83@asgcom.alaska-software.com...
> I was just about going home when I found following message in the
newsgroup  :
What?? you want to go home???  don't do it, you have to help us!! )


> Please send some lines of code describing the changes you have done.
> When using stream sockets there is no limitation in length. Just for fun I
have written a small application
> which sent
> 2 MB and 4MB of data through the network. I have had a lot of trouble with
it, but none of these problems
> could be
> reduced to a socket issue.

Here there the asinet socket example modified to read a file on the server

If I try with a small file (less then more or less 20k) it's all ok, but if
a file of 200KB this doesn't work, I don't know what's wrong...


>
> > Another question: how secure is sending/receiving  the strings  like the
> > CLIENT/SERVER examples? there should be some CRC check on the strings?
or
> > this is managed internally by the function send/recv?
>
> Such things are managed by the lowlevel protocols. Between two pieces of
hardware the ethernet protocol is
> responsible for example. Between sockets, the IP protocol is responsible.
> You need not worry about such questions, otherwise the internet would not
be as successfull as it is today.
>
So If I use the socketsend/recv I'm SURE that the data received is OK, else
I get an error, right?

thanks
Simone

"Simone Degl'Innocenti" <simone.degl@tin.it> schrieb im Newsbeitrag
news:3bb42f83@asgcom.alaska-software.com...
>
> "Andreas Herdt" <ah@de.alaska-software.com> ha scritto nel messaggio
> news:3bb34b83@asgcom.alaska-software.com...
> > I was just about going home when I found following message in the
> newsgroup  :
> What?? you want to go home???  don't do it, you have to help us!! )
>
>
> > Please send some lines of code describing the changes you have done.
> > When using stream sockets there is no limitation in length. Just for fun I
> have written a small application
> > which sent
> > 2 MB and 4MB of data through the network. I have had a lot of trouble with
> it, but none of these problems
> > could be
> > reduced to a socket issue.
>
> Here there the asinet socket example modified to read a file on the server
>
> If I try with a small file (less then more or less 20k) it's all ok, but if
> a file of 200KB this doesn't work, I don't know what's wrong...
>

Please have a look at server.prg. In the method ClientThread:execute() the server is checking how
many bytes can be read from the socket and then it reads the data.

I noticed that this is not save, since it might occur that only 1 or 2 bytes may be currently
available for a read request. Since a request in this sample never is too long the sample does
not fail by chance. This must be corrected for the next release and I have opened a pdr on the issue.

In the scenario of the sample the server should know
a) How long is a request, and read only one request at once, or
b) The client must send the length of the request in the first bytes of the request and then the
    server reads only one request by extracting the length of it from the first client.


http://www.alaska-software.com/cgi-bin/waa1gate.exe?WAA_PACKAGE=PUBLICDTS&WAA_FORM=DISPLAYPDR&PDRID=4648

Please have a look at the attached sample. It demonstrats another client server sample using sockets
in blocking mode. I hope this will help.


--


Andreas Herdt
Alaska Software Technology AG

-------------------------------------------------------------
Technical Support EMEA: mailto:support@de.alaska-software.com
Technical Support APRA: mailto:support@us.alaska-software.com
News Server:            news://news.alaska-software.com
Homepage:               http://www.alaska-software.com
-------------------------------------------------------------

Aah, a blocking mode sample at last!

Thanx!

Regards,

Phil Ide

Xbase++ FAQ
current release: 2,  Friday 20th July 2001, 17:55
****
* online  : http://www.idep.org.uk/xbase/xbfaq/xbfaq.htm
* download: http://www.idep.org.uk/xbase/xbfaq.zip
****

	"OK," says the clerk, writing it down, "how long you want 'em?"
	The guy gets the blank look again.  "Uh... I guess I better go
check," he says.
	He goes back out to the truck, and there's another animated
conversation.  The guy comes back into the office.  "A long time," he says,
"we're building a house".

"Phil Ide" <phil@idep.org.uk> schrieb im Newsbeitrag news:3bb89e17.85623940@news.alaska-software.com...
> Aah, a blocking mode sample at last!

Hey man,

This sample realy is no secret. I have posted it several times in the newsgroup.
(Please have a look at the thread "Dealing with sockets in non-blocking mode).
May be I have been too silent or you did not have enough coffee this day, so I shout loud:

I HAVE A NON-BLOCKING CLIENT-SERVER SAMPLE !!!!!!!!

And yes, It will be part of the next release. 


--


Andreas Herdt
Alaska Software Technology AG

-------------------------------------------------------------
Technical Support EMEA: mailto:support@de.alaska-software.com
Technical Support APRA: mailto:support@us.alaska-software.com
News Server:            news://news.alaska-software.com
Homepage:               http://www.alaska-software.com
-------------------------------------------------------------



> Thanx!
>
> Regards,
>
> --
> Phil Ide
>
> Xbase++ FAQ
> current release: 2,  Friday 20th July 2001, 17:55
> ****
> * online  : http://www.idep.org.uk/xbase/xbfaq/xbfaq.htm
> * download: http://www.idep.org.uk/xbase/xbfaq.zip
> ****
>
> "OK," says the clerk, writing it down, "how long you want 'em?"
> The guy gets the blank look again.  "Uh... I guess I better go
> check," he says.
> He goes back out to the truck, and there's another animated
> conversation.  The guy comes back into the office.  "A long time," he says,
> "we're building a house".

>Hey man,
>
>This sample realy is no secret. I have posted it several times in the newsgroup.
>(Please have a look at the thread "Dealing with sockets in non-blocking mode).
>May be I have been too silent or you did not have enough coffee this day, so I shout loud:
>
>I HAVE A NON-BLOCKING CLIENT-SERVER SAMPLE !!!!!!!!
>
>And yes, It will be part of the next release. 

Oooh, not so loud please .  I haven't been paying as much attention
to the NG's as I ought lately, been far too busy.  I'm back now though


Regards,

Phil Ide

Xbase++ FAQ
current release: 2,  Friday 20th July 2001, 17:55
****
* online  : http://www.idep.org.uk/xbase/xbfaq/xbfaq.htm
* download: http://www.idep.org.uk/xbase/xbfaq.zip
****

	"OK," says the clerk, writing it down, "how long you want 'em?"
	The guy gets the blank look again.  "Uh... I guess I better go
check," he says.
	He goes back out to the truck, and there's another animated
conversation.  The guy comes back into the office.  "A long time," he says,
"we're building a house".

There is a limit and it is not in the DOCS!
Don't worry about CRC, just set up a protacol and send your data in chunks
of 1k bytes or less.
After the block of data has been sent do a recive, the recieveing end should
send a byte after it has completed recieving the data, then begin recieving
data again.  At the sending end after confirmation of recieving sned another
block, until complete. I use the sample modified just a bit, and send four
bytes U2Bin( 0 ) for the last block. It works fine.

I have an APP on the web using ASINET, it can send unlimited information to
a dialup with out problems.

-Bruce

PS I would sugest you setup incryption otherwise a few hacker Xbase programs
may decide to mess with your site.

"Simone Degl'Innocenti" <simone.degl@tin.it> wrote in message
news:3bb18398@asgcom.alaska-software.com...
> Hello
>
> I modified the CLIENT/SERVER examples to send the contents of a file from
> the server to the client but the client doesn't receives only the first
6Kb
> (more or less) of the string the server sends
> Why?
> the docs for socketsend says that only if UDP is used there is size limit
of
> the string to send
>
> Another question: how secure is sending/receiving  the strings  like the
> CLIENT/SERVER examples? there should be some CRC check on the strings? or
> this is managed internally by the function send/recv?
>
> thanks
> Simone
>
>
>
>
>

Hi,
I've just come to that problem too. I find that if my sender (client) pgm sends
out 1024 byte blocks, the receiver(server) get a block smaller 1024 byte after
receiving about 8600 byte or so. That means for that block a second read.
The samples are modified server client templates (without any error handling!!)
for testing a 2 GB traffic on the network. (I'm not sure what component causes
the problem, but could be the sockets. Ethernet frames must be around 1500 byte
or so, means this is more than 1 frame)
Donald


Bruce Raisley schrieb:

> There is a limit and it is not in the DOCS!
> Don't worry about CRC, just set up a protacol and send your data in chunks
> of 1k bytes or less.
> After the block of data has been sent do a recive, the recieveing end should
> send a byte after it has completed recieving the data, then begin recieving
> data again.  At the sending end after confirmation of recieving sned another
> block, until complete. I use the sample modified just a bit, and send four
> bytes U2Bin( 0 ) for the last block. It works fine.
>
> I have an APP on the web using ASINET, it can send unlimited information to
> a dialup with out problems.
>
> -Bruce
>
> PS I would sugest you setup incryption otherwise a few hacker Xbase programs
> may decide to mess with your site.
>
> "Simone Degl'Innocenti" <simone.degl@tin.it> wrote in message
> news:3bb18398@asgcom.alaska-software.com...
> > Hello
> >
> > I modified the CLIENT/SERVER examples to send the contents of a file from
> > the server to the client but the client doesn't receives only the first
> 6Kb
> > (more or less) of the string the server sends
> > Why?
> > the docs for socketsend says that only if UDP is used there is size limit
> of
> > the string to send
> >
> > Another question: how secure is sending/receiving  the strings  like the
> > CLIENT/SERVER examples? there should be some CRC check on the strings? or
> > this is managed internally by the function send/recv?
> >
> > thanks
> > Simone
> >
> >
> >
> >
> >