× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




On 18/12/2009, at 9:12 AM, GKern@xxxxxxxxxxxxxxxx wrote:

Is there any way to trap/detect if a data stream is larger than the what
the socket's input field can handle?

Only if the data stream is structured and contains a length prefix. That's determined at the application level. TCP doesn't know or care.

You need to receive data from the socket until:
a) Some end-of-data indicator is received
b) Receiver KNOWS all data is received
c) EWOULDBLOCK is received on the socket
d) A timeout occurs on the receive
e) The sender closes the connexion

a) and b) requires agreement between sender and receiver
c) requires the socket be set to non-blocking mode
d) requires the use of select()


Can I extract a portion of the data?

You can read it a byte at a time if you like but of course that's less efficient. Just read it in chunks of some convenient size.


I ask that since I've been testing receiving data streams over 32k, but in
debug the data appears as a string of @'s and I'm not sure what's causing
that. I'm assuming it's 'error' related.

ASCII @ signs have the same hex representation as EBCDIC spaces (at least in the most common US code pages) so it's likely what you're seeing is really a bunch of blanks. Note that you can't necessarily rely on that--it's likely the blanks are there as a result of initialised storage that hasn't yet had anything written to it. You should only process the amount of data that recv() indicates was received.


The numerous things I've tried (including searching the archives and the
net) have left scratching my head as to how to proceed.

Also I know that QDCXLATE is limited to 32767 bytes. Are there any
alternatives for translating text larger than 32k or should I just
deconstruct and then reconstruct it in 32k chunks?

The iconv suite of functions are the preferred way to convert data from one CCSID to another.


At the very least I'd like to be able to detect a large string, pull some
identifiable data out of it and send off an email to the sender letting
them know I can't handle data stream larger than x bytes long. Does that
make sense?

No sense at all. A socket program ought to be able to handle however much data is sent to it.

If you must then simply track the number of bytes received from the sender and when some arbitrary threshold is reached complain. You'll still have to receive the rest of what is sent else it will remain for the next receive operation.

Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.