Re: How to stop UDP port 86 BroadCast


In article <1117446630.226392.212680@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, "MalhiNet" <m_nets2003@xxxxxxxxx> writes:
>
> Is it possible multipal CCITCP server can talk to each other without
> using UDP port 86 broadcast.

This isn't a COBOL question, so it's not topical for comp.lang.cobol.
I recommend raising it as an issue through your Micro Focus support
representative.

> We have a large system which is running on CCITCP on every server on
> WAN. when server-A want to connect to server-B It sends the UDP port
> 86 broadcast on all WAN then server-B replay it.
>
> UDP port 86 broadcast is creating problem for netwrok.

IP broadcasts shouldn't traverse a WAN at all, regardless of what
process generates them. If they are, then you have a suboptimal
network which is bridging LAN segments. Personally, I'd recommend
you correct that, if at all possible; broadcasts should not be
carried over WAN links.

Also, you don't need more than one ccitcp2 process per LAN segment
(though there are some possible reasons for running more). If you
have a ccitcp2 running on every server system, and there's more than
one server system per LAN segment, then you have too many ccitcp2s.

> If any one know why it is doing UDP Broadcast and how can i remove it.

Programs using CCITCP use UDP broadcasts to locate ccitcp2 if they
haven't been configured with the location of the ccitcp2 daemon. The
easiest way to do that is to set the CCITCP2 environment variable,
per MF documentation. Have you done that?

ccitcp2 itself will use a UDP broadcast to relay a query for a server
that is not registered with it.

If your CCITCP-based programs have their ccitcp2 locations configured
manually (eg using the CCITCP2 environment variable), and they only
request servers which are known to the ccitcp2 they're configured to
use, that should eliminate most of the UDP broadcasts.

Alternatively, use CCI Direct Connect rather than ccitcp2 name
resolution. See the documentation for your MF COBOL product for
details.

For further information, please raise an MF support request or take
this question to the Micro Focus Forum (formerly Answer Exchange) on
the Micro Focus Supportline web site.[1]


1. http://supportline.microfocus.com/about/forum.asp

--
Michael Wojcik michael.wojcik@xxxxxxxxxxxxxx

HTML is as readable as C. You can take this either way. -- Charlie Gibbs
.

Relevant Pages

  • Re: Suggestion
    ... Yes database is a single point of failure, but that's not relevant in my ... But if the socket server goes down all of the clients are down - single ... Use UDP and a broadcast, have all clients monitor the same UDP ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Tcl-Tk and network.
    ... >> that it didn't work for broadcast. ... >> the server side of this and send raw UDP packets from a compiled C ... And shows up in the "server" tclsh process: ...
    (comp.lang.tcl)
  • Re: Suggestion
    ... But if the socket server goes down all of the clients are down - single ... Use UDP and a broadcast, have all clients monitor the same UDP ... I am wondering how you don't have a central point of failure with a ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: client-server network
    ... the msg using sendto..then waits for a reply from the server using ... sent by server didn't reach the client...... ... Note that for broadcast, you must set the SO_BROADCAST option, which your ... UDP might not be better than TCP, ...
    (microsoft.public.vc.mfc)
  • Re: Registration of more then 1 CCITCP2 Servers
    ... CCITCP2 is not part of, or related to, COBOL. ... They should be addressed to your Micro Focus Support ... Why are your WAN links configured to propagate broadcast packets? ...
    (comp.lang.cobol)