Is it more appropriate for an irc client to use non-blocking sockets?
if so, why? Currently my bot uses blocking sockets but I have been
told that non-blocking sockets are preferred except they never
provided any reason as to why they are preferred.

[ Post a follow-up to this message ]

j0mbolar wrote:
> Is it more appropriate for an irc client to use non-blocking sockets?

yes.

> if so, why?

to avoid blocking (not THAT blocking, see below).

> Currently my bot uses blocking sockets but I have been
> told that non-blocking sockets are preferred except they never
> provided any reason as to why they are preferred.

Suppose:
- You want to write 8192 bytes of data into the socket.
- The socket buffer size is 4096 (kind of low, but illustrative)
- The IRC server is malicious.

If you're doing write(sockfd, buf, 8192), the client will block
until part of data is drained. If the IRC server is malicious, it
can prohibit receiving data by making its receive buffer zero.
Your TCP stack will not be able to push data to a remote system,
and your bot will freeze. This situation may persist for indefinite
amount of time.

In some variation of this scenario it is possible to harm your
client even if IRC server is not malicious.

--
Lev Walkin
vlm@lionet.info

[ Post a follow-up to this message ]

Lev Walkin wrote:

> If you're doing write(sockfd, buf, 8192), the client will block
> until part of data is drained. If the IRC server is malicious, it
> can prohibit receiving data by making its receive buffer zero.
> Your TCP stack will not be able to push data to a remote system,
> and your bot will freeze. This situation may persist for indefinite
> amount of time.

So only make the write call when you know the socket is ready for write,
which select/poll indicates for you.

--
__ Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
/  \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ Love is not love which alters when it alteration finds
-- William Shakespeare, _Sonnets_, 116

[ Post a follow-up to this message ]

Erik Max Francis wrote:
> Lev Walkin wrote:
>
> 
>
>
> So only make the write call when you know the socket is ready for write,
> which select/poll indicates for you.

Select/poll indicates only _writeability_. It does not tell you anything
about ability to write the whole amount without blocking.

--
Lev Walkin
vlm@lionet.info

[ Post a follow-up to this message ]

Lev Walkin wrote:

> Select/poll indicates only _writeability_. It does not tell you
> anything
> about ability to write the whole amount without blocking.

That's why you only try to empty an application-side client buffer in
chunks that are smaller than the system-side socket buffer.

--
__ Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
/  \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ Love is not love which alters when it alteration finds
-- William Shakespeare, _Sonnets_, 116

[ Post a follow-up to this message ]

On Fri, 23 Jul 2004 01:37:12 -0700 Erik Max Francis <max@alcyone.com> wrote:
> Lev Walkin wrote:
> 
>
> So only make the write call when you know the socket is ready for write,
> which select/poll indicates for you.

No it doesn't, select/poll indicates writability of at least 1 byte, only,
and only at the time it is called.  By the time you actually do the write,
your call may block.  When using select/poll, you must always use non-
blocking sockets.

/fc

[ Post a follow-up to this message ]

Erik Max Francis wrote:
> Lev Walkin wrote:
>
> 
>
>
> That's why you only try to empty an application-side client buffer in
> chunks that are smaller than the system-side socket buffer.
>

Okay. What about reads? You can easily block on read, when the remote
side is awaiting some data to be send from your process.

--
Lev Walkin
vlm@lionet.info

[ Post a follow-up to this message ]

Lev Walkin wrote:

> Okay. What about reads? You can easily block on read, when the remote
> side is awaiting some data to be send from your process.

Select/poll also indicates readability.  If you don't try to read from
the socket unless select/poll says it's ready for reading, you never
block.

--
__ Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
/  \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ Love is not love which alters when it alteration finds
-- William Shakespeare, _Sonnets_, 116

[ Post a follow-up to this message ]

Erik Max Francis wrote:
> Lev Walkin wrote:
>
> 
>
>
> Select/poll also indicates readability.  If you don't try to read from
> the socket unless select/poll says it's ready for reading, you never
> block.

Never? Even if another thread or a process sharing this descriptor reads thi
s
data before you get a chance to read it yourself?

Too many "but's".

--
Lev Walkin
vlm@lionet.info

[ Post a follow-up to this message ]

Lev Walkin wrote:

> Never? Even if another thread or a process sharing this descriptor
> reads this
> data before you get a chance to read it yourself?

Only one thread and one process should be processing sockets.  There are
race conditions all over the place if that's violated, and to fix those
you need mutexes for each socket which gets incredibly expensive.

One process, one thread handles socket transactions.  That process has
application-side read and write buffers, and uses select/poll to read
and write from ready sockets when select/poll indicates that they're
ready for read or write.  That's all.

> Too many "but's".

You're the one inventing the _buts_.  They're not relevant.

--
__ Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
/  \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ Adultery is the application of democracy to love.
-- H.L. Mencken

[ Post a follow-up to this message ]