commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Leong (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (NET-638) Telnet subnegotiations hard-limited to 512 bytes
Date Thu, 29 Jun 2017 17:22:00 GMT

     [ https://issues.apache.org/jira/browse/NET-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Daniel Leong updated NET-638:
-----------------------------
    Description: 
Currently using Commons.net's Telnet client for connecting to MUD/MUSH servers, and some servers
use subnegotiation for sending out-of-band data with more than the hard-coded 512 bytes that
TelnetInputStream limits it to. It looks like it would be straightforward to add an (optional)
int constructor parameter to TelnetClient that passes it to a similar, new TelnetInputStream
constructor parameter.

I've got a workaround using a bunch of reflection, but it'd be nice to not need that.

  was:
Currently using Commons.net's Telnet client for connecting to MUD/MUSH servers, and some servers
use subnegotiation for sending out-of-band data with more than the hard-coded 512 bytes that
{code:java}TelnetInputStream{code} limits it to. It looks like it would be straightforward
to add an (optional) int constructor parameter to TelnetClient that passes it to a similar,
new TelnetInputStream constructor parameter.

I've got a workaround using a bunch of reflection, but it'd be nice to not need that.


> Telnet subnegotiations hard-limited to 512 bytes
> ------------------------------------------------
>
>                 Key: NET-638
>                 URL: https://issues.apache.org/jira/browse/NET-638
>             Project: Commons Net
>          Issue Type: Improvement
>          Components: Telnet
>    Affects Versions: 3.6
>            Reporter: Daniel Leong
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Currently using Commons.net's Telnet client for connecting to MUD/MUSH servers, and some
servers use subnegotiation for sending out-of-band data with more than the hard-coded 512
bytes that TelnetInputStream limits it to. It looks like it would be straightforward to add
an (optional) int constructor parameter to TelnetClient that passes it to a similar, new TelnetInputStream
constructor parameter.
> I've got a workaround using a bunch of reflection, but it'd be nice to not need that.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message